Tag: VPS

Cloud-Native Best Business Practices (Part 2): Why Cattle, Not Pets

Cloud-Native Best Business Practices (Part 2): Why Cattle, Not Pets

To quote Michael Dell, “The cloud isn’t a place, it’s a way of doing IT.” As IT becomes more and more central to what every company does, understanding cloud-native best practices is key, not only for developers, but for every part of a business.

This post is the second of a seven-part series examining how cloud-native best practices can help businesses deliver value to their customers better, faster, and cheaper. This part explains the Pets vs. Cattle analogy and how it can help business provide a better service with faster time to recovery which reduces lost revenue.

History: Pets vs. Cattle

The analogy of Pets vs Cattle has become one of the core concepts of a DevOps service model. The idea was first introduced by Bill Baker, a Distinguished Engineer at Microsoft, in his presentation “Scaling SQL Server 2012” and later popularized by Gavin McCance talking about the OpenStack cloud at CERN. The difference between Cattle and Pets is how vital each individual is to you. To pull from Randy Bias’ post on the history of this analogy:

In the old way of doing things, we treat our servers like Pets, for example, Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like Cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot, and replaced on the line.

Pets are each vitally important, but Cattle are interchangeable. Moving production software infrastructure from Pets towards Cattle is key to creating a highly available (HA) system with reduced failures, a smaller blast radius, and faster disaster recovery. Taken together, moving towards a Cattle service model helps businesses deliver a better service with reduced downtime.

Cloud-Native Best Practices: Pets vs. Cattle

Reliably running and managing scalable IT infrastructure necessitates using Cattle and Kubernetes clusters will be no different. Joaquin Menchaca’s blog nicely traces the evolution from a Pet to Cattle management model up the stack from bare metal servers to cloud-native containers and container orchestrators. At each stage, a higher layer of the stack becomes replaceable. creating immutable production where only exact copies are deployed and they can be replaced at any time. If anything needs to be changed, a new deployment is made and the old ones are decommissioned. Immutable production eliminates variations leading to fewer deployment failures, consistency across environments, easy horizontal scaling, and a simple rollback and recovery process.

To take advantage of these benefits and bring immutable containers into production, Kubernetes has become the de facto standard because it simplifies the process of deploying and orchestrating containers. However, installing, managing, and updating Kubernetes itself is no simple undertaking. To avoid these challenges, clusters have become the new Pets, with companies running a few large vital clusters rather than multiple smaller replaceable clusters. This is in direct contradiction to the cloud-native principles Kubernetes was founded on. To derive the full value from a cloud-native approach, it is imperative that companies treat their Kubernetes clusters like Cattle, too. Spinning them up and down on demand and treating them as disposable, replaceable assets rather than prized Pets.

Beyond easing management and saving operations time and money, running Kubernetes clusters as Cattle can have a real impact on the bottom line, too. For example, an e-commerce company earning 5 billion euros per year is completely dependent on their shop being online. Every minute of production outage is 10,000 Euros in missed sales. In a case study with the CNCF, when VSCO standardized their provisioning and outage recovery with Kubernetes, they reduced their outage time by 88%. The Cloud Native Computing Foundation is already seeing businesses transition towards using Kubernetes clusters like Cattle. In the past six months, organizations running 1-5 production clusters decreased 37%, while organizations running 11-50 clusters increased 154%. Treating infrastructure as Cattle allows companies to simply replace their infrastructure and come back online sooner, saving sales.

At Loodse, we strongly believe in treating Kubernetes clusters as Cattle. We use multiple tools to make it as easy as possible for our developers and operators to create and use Kubernetes clusters including kind and KubeOne, and Kubermatic. We use kind to quickly spawn Kubernetes clusters to run integration and E2E tests in our CI/CD pipeline. We recently open sourced KubeOne because it gives developers the ability to quickly install, manage, and upgrade highly available Kubernetes clusters on any cloud provider, on-prem, or bare-metal cluster. Furthermore, we are actively contributing to t cluster-api in upstream Kubernetes to simplify the process of cluster creation, configuration, and management. Finally, when we designed Kubermatic for large-scale installations, we followed this best practice of turing clusters into Cattle, too. This requires that creating, updating, and deleting a Kubernetes cluster is only one click away for anyone. Kubermatic does this by spinning up the user cluster Kubernetes control components as containers in the seed Kubernetes cluster (architecture details here). If anything happens to a control component of the worker cluster, it will be automatically restarted and replaced by the seed Kubernetes cluster turning the control components and cluster itself into cattle.

Conclusion

Running Cattle rather than Pets is a computing infrastructure best practice no matter what layer of the stack. It provides customers a better service, reduces time to recovery, and eliminates lost revenue from production outages. Kubernetes became the standard for container orchestration because it allows you to treat your containers like Cattle. Kubernetes clusters themselves should be treated like Cattle too.

from DZone Cloud Zone

Migrating to the Cloud? Here’s Why Automation is Essential

Migrating to the Cloud? Here’s Why Automation is Essential

Nearly 60 percent of North American enterprises now rely on cloud platforms, according to a recent Forrester survey. The benefits of cloud are well known, but the question marks that remain have left a significant number of organizations hesitant to make the jump.

Several factors can slow down a company’s decision to adopt the cloud. Many organizations have the pre-conceived notions that cloud adoption comes with security risks and threats of data leakage. In reality, on-premise is probably just as risky than those fronts.

Plus, after a company has come to the decision to adopt the cloud, it can take a lot of time using traditional methods to design, develop and deploy the data infrastructure needed and migrate the desired data. Luckily, automation software can lessen the work.

Fast-Tracking an Organization’s Journey to the Cloud

With automation software, moving to the cloud is easier than ever before. Companies leveraging automation software can increase the success of data infrastructure cloud migration projects and shorten the time to value of that investment. Here’s how automation can help enterprises make the move to the cloud:

1. Helps Provide the Framework for An Agile Environment

As time evolves, so do data and analytics requirements. Data warehousing teams moving to the cloud have a fresh opportunity to re-examine current processes and improve how they will work given this new landscape. The ability to address changing requirements and new business needs more quickly without disrupting functions is desirable to every organization. This requires agility in terms of multiple iteration support. Data infrastructure automation enables IT teams to be more efficient and effective, creating an agile data warehousing environment.

2. Shrinks the Timeline to The Cloud

Before automation, migrating to the cloud was a long and grueling manual process that required a high-level of precision and was prone to human error. The conventional way has been overcomplicated and inefficient. Automation software provides data warehousing teams with full life cycle management from design and development through deployment, operations and even documentation – resulting in accelerated time to production. Leveraging automation within migration efforts can also ensure you are able to preserve the structure and integrity of migrated data. With automation, data warehousing processes become streamlined and more efficient and migration to the cloud can be accomplished much more quickly.

3. Decreases Costs by Getting Time Back

Moving to the cloud can be a costly investment both financially and otherwise. According to a recent Forrester report, labor costs can make up half of cloud migration projects. Since automation better facilitates and quickens the process, organizations can eliminate some of the more repetitive tasks needed to move to the cloud and reduce these costs. Existing data warehousing teams embarking on cloud migration projects are often able to then tackle the effort without the burden of hiring additional staff. In addition, automation delivers consistency and universal team guidelines, resulting in less chance of human error or cost-accruing delays down the line in understanding and/or troubleshooting a previous developer’s approach. Automation frees up staff time to focus on the higher-value, more strategic aspects of cloud data warehousing.

Adding Value to Your Cloud Journey

Automation is helping IT teams globally to speed up the data infrastructure lifecycle by up to 80 percent to better support data analytics needs. With automation, the data infrastructure feeding analytics becomes more consistent and reliable, giving the business improved access to timely enterprise data to better operate. In turn, analytics can power more efficient workflows and higher satisfaction rates for an organization’s customer base. Furthermore, being able to evolve the organization’s data infrastructure to better respond to new business needs becomes less painful and easier to achieve.

With the automation benefits of faster project delivery, lower risks and costs, and an increase in team productivity, those who are ready to pursue a move to the cloud no longer have to fear not being successful in a cloud migration project. Additionally, teams can rely on metadata-based automation to provide extra peace of mind that they will also be able to easily move, regenerate and optimize their cloud data warehouse for new data platforms if needed in the future. 

Whether organizations continue to rely on on-premises data warehouse platforms, migrate to the cloud or manage a hybrid environment of both for awhile, teams can use automation to provide more to the business faster. Data infrastructure automation allows data warehousing teams to be more efficient, add more value and innovate.  

from DZone Cloud Zone

The 4 AWS Pricing Principles with a Critical Eye

The 4 AWS Pricing Principles with a Critical Eye

Amazon Web Services advertises four principles that guide their pricing strategy – pay as you go, pay less by using more, save when you reserve, and their free tier. These principles provide immense benefits and efficiencies for thousands of organizations, which has driven AWS’s stellar growth. But there are downsides as well. In this article we’ll review the five principles and provide a grain of salt you should consider before hooking into the Amazon machine.

Principle #1: Pay as You Go

  • The Principle: This is the main idea behind AWS – instead of buying or building costly infrastructure, rent it. AWS is dedicated to turning your CapEx expenses into OpEx. It also provides extreme flexibility – you can order 1,000 machines for an hour and then stop them and pay only for those 1,000 machine hours.

  • The Good: It’s why organizations started moving to the cloud. Pay per use is great because it eliminates overcapacity and wasted computing resources.

  • The Bad: Flexibility comes at a cost. If you want to really “pay as you go”, you’ll have to settle for Amazon’s On-Demand Pricing, which becomes quite expensive even for small workloads, when used for ongoing server deployments. Truth be told, most servers don’t have huge peaks or troughs in their usage – and running them on dedicated hosting or on-prem will be a lot cheaper than on Amazon.

Principle #2: Pay Less by Using More

  • The Principle: AWS provides volume discounts. Amazon S3 and many other services offer tiered pricing, and Amazon EC2 offers volume discounts for users who spend more than $500,000 in upfront costs. Amazon also provides a plethora of services and options for most use cases, allowing you to switch to a service that meets your need at a lower cost. For example, there are several AWS backup options including the AWS Backup service and storage services like S3, Glacier, EBS, EFS, etc. Organizations can move data between these storage services to gain efficiencies.

  • The Good: Sophisticated users of AWS can save a lot by dynamically moving workloads between services and creating economies of scale.

  • The Bad: This principle is also one of the hidden reasons for Amazon’s enormous complexity. True – you can create a tiered storage strategy and save 90% or more in many cases. But do your engineers or IT staff know the intricacies of each data service, and have the know-how to detect the relevant events and store data selectively into different data stores? Amazon provides the tools to do all this. But it requires time and expertise which by itself costs organizations serious money.

Principle #3: Save When You Reserve

  • The Principle: At the core of AWS is its compute service, Amazon EC2. EC2 machine instances are substantially discounted (on the order of 30-50%) if you reserve an instance for 1-3 years in advance. Another option is to use “spot instances” – machine instances that happen to be available at a given time, and will be taken away from you when another user demands them. Switching loads dynamically between spot instances, and helping Amazon manage their demand, can give you even bigger discounts.

  • The Good: Amazon provides a lot of price flexibility. You can significantly cut costs by committing to 1 years or more – it’s possible to do this selectively for some workloads, while using others on demand. The spot instances option is a creative one, which lets anyone with expertise, and the time to architect a spot instances solution, shave 60% off costs.

  • The Bad: Committing to a machine instance for 1 to 3 years on the cloud might sound like an oxymoron. Organizations are moving to the cloud to get computing resources on demand. A long-term financial commitment flies in the face of this flexibility. Many AWS users take on-demand prices as a given, and pay the price of flexibility.

Principle #4: Free Usage Tier

  • The Principle: Amazon grants 1 year of free usage with generous quotas for many of its services, to reduce risk and encourage cloud adoption. This was a primary way AWS gained its initial market share in the early years.

  • The Free Tier Grants (as of the time of this writing) 1 year of usage with 750 hours of EC2 instances, 750 hours of RDS usage (can run managed databases like MySQL), 5 GB on S3, 1 million requests on the cool serverless delivery platform Lambda, 50 GB storage on CloudFront (delivery network), 5GB on EFS (file storage), 30GB on EBS (block storage), 750 hours of ElasticSearch, and more.

  • The Bad: The free tier has helped many organizations and technologists get “hooked” on Amazon’s offerings – it is a showcase of the astounding depth, breadth and technical excellence of their service profile. Amazon provides – and encourages – an enormous amount of sophistication within its ecosystem. It provides power, but power brings with it responsibility, overhead and a high cost of skills. Very often, organizations select AWS by default because it is a market leader and the option most well known by their teams. I can’t say the free tier is bad, but it has creatd an unfair advantage vs. other cloud offerings, which have their own strengths.

Wrap Up

AWS is great, but it is also a business and has established pricing that safeguards its interests. Carefully consider the benefits and tradeoffs of the Amazon pricing philosophy before entering a large-scale engagement. If you’re already heavily engaged, plan your cloud consumption 1-2 years ahead and see if other cloud platforms – such as Azure or Google Cloud Platform – can give Amazon a run for its money.

from DZone Cloud Zone

Some Notes Regarding Docker, Kubernetes, and Azure Pipelines

Some Notes Regarding Docker, Kubernetes, and Azure Pipelines

Docker Compose

What is Docker Compose?

Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration.

  • In docker-compose.yml file, we will list all services (web API, frontend, DB, etc.)
  • Check the validity of YML file by running docker-compose config (path or space if inside the path where the file is)
  • Fix any issue in the docker-compose.yml file
  • Run all services (containers) by running docker-compose up -d
  • Stop all services (containers) by running docker-compose down

Install Docker Compose

sudo curl -L "https://github.com/docker/compose/releases/download/1.24.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

Here’s where you can find more info about Docker Compose as well as how to build docker-compose.yml.

For more information about how to work with Docker like pulling a Docker image, running a Docker image, and working with containers, see Docker for beginners.

Docker Multi-Stage Build and Docker Builder Pattern

Docker Builder Pattern

It involves two Docker images with two Dockerfiles. One for each image:

  1. “build” image with all the build tools installed, capable of creating production-ready application files.
  2.  “service” image capable of running the application. 

Docker Multi-Stage Build

Multi-stage builds are a new feature requiring Docker 17.05 or higher. It helps to optimize Dockerfiles while keeping them easy to read and maintain. So, I can have multiple From in the same Dockerfile, which means I can implement a builder pattern without maintaining many Dockerfiles.

We define each stage using AsStage Name in the From statement. e.g

  •  From myImageName As build
  • From myImageName AS test 

I can also use the stage as my base image instead of using image e.g:

  •  From myImageName As build 
  •  From build As test 

So I create the stage for a purpose, for example, to build the application, to unit test the application, and then copy my application or test result (artifacts) to a mounted volume, then copy artifact from mounted volume to another stage if needed. In the final stage, I create the image that I will deploy to the prod.

The main idea is that if I have a stage image, I don’t need it as a stored image. I just need to have it on the fly to produce some files and that’s it. I only create and store images that I need to be deployed to an environment

Docker Create

The docker create command creates a writeable container layer over the specified image and prepares it for running the specified command. The container ID is then printed to STDOUT. This is similar to docker run -d except the container is never started. You can then use the docker start <container_id> command to start the container at any point.

This is useful when you want to set up a container configuration ahead of time so that it is ready to start when you need it. The initial status of the new container is created.

More info about Docker multi-stage build and Docker create here. For more information about how to work with Kubernetes cluster and deploy it to Azure Kubernetes Service (AKS) and work with Azure Container Registry, see Kubernetes cluster for beginners.

COPY vs. ADD in a Dockerfile

COPY and ADD are both Dockerfile command that serve similar purposes. Copy files from a specific location into a Docker image.

COPY takes in a src and destination. It only lets you copy in a local file or directory from your host (the machine building the Docker image) into the Docker image itself.

ADD lets you do that, too, but it also supports two other sources. First, you can use a URL instead of a local file/directory. Secondly, you can extract a tar file from the source directly into the destination.

Copy Files Over SSH task (Azure Pipeline)

Use this task in a build or release pipeline to copy files from a source folder to a target folder on a remote machine over SSH.

SSH Task (Azure Pipeline)

Use this task in a build or release pipeline to run shell commands or a script on a remote machine using SSH. This task enables you to connect to a remote machine using SSH and run commands or a script.

Shell Task (Azure Pipelines)

Use this task in a build or release pipeline to run a shell script using bash.

Links:

Bash and PowerShell reference

from DZone Cloud Zone

Five Ways To Modernize Your Apps And Infrastructure

Five Ways To Modernize Your Apps And Infrastructure

Is your business ready to modernize? Here are five considerations that will help you realize a pathway to progress.

Before embarking on a modernization initiative, classify your existing applications first. This process helps determine which apps are the low-hanging fruit and those that will take longer to modernize (or should just be left alone). A simple example is Windows versus Linux. Cloud-native technology stacks historically have favored Linux. Technology vendors like Docker, however, have made contributions to running Windows apps on containers, but these are still not as mature as Linux. Having a clear understanding of how many Windows apps are being run today can help you understand which technologies would make more sense to utilize.

What about single-purpose applications? Modernizing is easier if an application is already well decomposed into distinct responsibilities and components. If it’s monolithic, that usually means combining a bunch of components into a virtual machine, with tight dependencies between each other. Those applications will tend to be more difficult to modernize.

Another application classification is stateful versus stateless. Most modern application frameworks are optimized for stateless applications, which makes it easy to scale up and down a particular component of an application. Stateful applications like databases, message queues and key-value stores tend to take longer to modernize.

Considering the delivery vehicle(s) for your applications will help determine if you should be using virtual machines, containers or serverless functions. Modern application design patterns are actually based on the principles of scalability, statelessness and high availability – and can still be delivered by using a virtual machine. There’s no rule for having to use containers or functions. For example, Netflix runs their services in a highly scalable and available form, using many of the design principles of modern applications, and the company has been using virtual machines for many years.

Sometimes the most suitable delivery vehicle for an application is based on preferences. A developer team may be more comfortable with one vehicle type versus another, which affects the choices in technologies and frameworks used to run those workloads.

Another thing to consider is deployment targets. Is there a move to the public cloud coming, or is there a need to keep apps hosted on premises? Perhaps there is a combination of public cloud and private data centers? Ensure that whatever technology stack is chosen will be predominantly open-source because there will be better chances for interoperability or portability across clouds or environments and you can avoid lock-in.

3) Decompose Apps Early And Often

Decomposing your applications into services is really important. To “decompose” your apps, try to draw lines around the pieces of your applications that serve different functions, then see (for each of these service tiers) whether they’re stateless and whether they can be scaled horizontally. For example, a database tier can be left alone and continue to use a specialized external database with a dedicated team running on local hardware. But if an application has a tier that is stateless and can be scaled horizontally, that’s a good candidate to modernize, repackage and target for a container or a function type of platform.

When packaging scalable service tiers, decide if they will run in a container or run in a function. Regardless of what you choose, you can always rely on the standard for creating modern apps, which is called Twelve-Factor. These 12 recommendations for how to build and configure a modern application will cover everything from the codebase to administrative processes.

Applications that are already well organized into recognizable tiers are good candidates to modernize because their decomposition has already been architected. For example, three-tier apps composed of a web frontend, an application service and a database tend to be easier to modernize.

4) Kubernetes to the Rescue

Once an app is architected, Kubernetes, an open-source software platform, will help with the operational aspects of running those applications. One example is automatic healing. If there is a service that can support and number replicas of an application, Kubernetes can automatically scale up and down based on demand. If a workload or a replica dies, Kubernetes will automatically replace it. Kubernetes also helps with service discovery by automatically configuring its own DNS server to register the application name in its registry, so that other applications can discover the existence of the new app and get an IP address back to be able to connect to the app.

Making investments into containerizing an application helps with modernizing apps and future-proofing. Kubernetes is the de facto standard for container orchestration, and it provides portability and a more robust operational practice. While Kubernetes is great, it is notoriously difficult to deploy and operate on an enterprise scale — particularly when running on mixed infrastructure. Consult different solutions designed to help you take advantage of Kubernetes in production to see which one is best for your needs.

5) Serverless Accelerates Modernization

Kubernetes has dozens, if not hundreds, of complex abstractions and concepts that need to be learned right out of the box. But, if people have a good grasp of what an application needs and follow many of the practices previously discussed, embracing a serverless framework is the next step.

If serverless is a good fit for an application, it can provide a boost by significantly simplifying the process of app modernization. A serverless framework should run an application in the most optimal and scalable way possible.

Conclusion

By modernizing your applications and infrastructure, your organization can develop faster, operate more easily and scale independently. Modernizing requires a lot of consideration, but many of these functions will help your team achieve great granularity in your processes and help your applications better respond to daily events. How will your business take the leap?

from DZone Cloud Zone

Beyond Serverless: Why We Need A Stateful Data Fabric

Beyond Serverless: Why We Need A Stateful Data Fabric

The first iPhone was released on June 29, 2007. And while the advent of the iPhone was hardly the only catalyst of the smartphone revolution, I consider this to be as good a birthdate as any for one of humankind’s most consequential innovations. Since then, smartphones have been adopted faster than any other disruptive technology in modern history. But I’m not actually here to write about smartphones, because I think there was an even more important development that day in 2007. That development that changed the world? It was the announcement of the iOS operating system.

In my opinion, iOS changed how humans fundamentally interact with technology, in ways that will far outlast the smartphone era. What I mean is that iOS brought apps into the mainstream. Don’t get me wrong, we’ve been calling application software “apps” since at least 1981. And this didn’t just happen overnight. Until 2010, Symbian was the world’s most widely used smartphone operating system. But iOS crystallized the modern notion of how users engage with apps, and made them accessible to users with even the most limited technical ability. Like written language, the printing press and telecommunications before, apps have changed how we communicate with the world.

From Microservices to Serverless

*That seems like an awfully long lead-in for article about data fabrics…*

I know, I know. Thanks for sticking with me. The reason all this is important is because, while iOS changed users’ relationships with apps, it also changed our relationships with application infrastructures. Instead of shipping bytes of static data from one machine to another, apps now needed to interact with dynamic, continuously changing datasets. Whether data was being generated by mobiles users, sensors, or devices; traditional SQL database architectures were soon stretched to their limits by this new generation of mobile apps. Apps were now expected to be reactive, real-time, and highly available while dealing with unprecedented volumes of data being created. A new generation of specialized data processing and networking software would have to be created as the foundation for this new generation of apps.

Around this time, we saw the rise of microservices architectures and actor-based systems like Akka. We also saw the dawn of AWS and public cloud services. A new class of social media apps created the need for real-time databases like Apache Cassandra and performant message brokers like Apache Kafka. Today, microservices have become a ubiquitous part of enterprise architectures. And we’re starting to see even newer paradigms like serverless.

While serverless seeks to decouple an app’s operations from its infrastructure, this is only a first step. Mike Roberts defines two primary implementations of serverless, Backend-as-a-Service (BaaS) and Functions-as-a-Service (FaaS). In the former, Roberts explains BaaS applications “significantly or fully incorporate third-party, cloud-hosted applications and services, to manage server-side logic and state.” Most of these are rich front-end applications, where a relatively inflexible server-side architecture is perfectly cromulent and can be outsourced to multiple vendors. For the latter, FaaS apps are “run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a third party.”

This model works great for ephemeral tasks, but what about continuous processes with continuously variable event streams? These streaming apps would be better served by a stateful network of serverless functions.

One way to accomplish this is by creating a stateful data fabric.

So What Exactly is a Data Fabric?

According to Isabelle Nuage, a data fabric is “is a single, unified platform for data integration and management that enables you to manage all data within a single environment and accelerate digital transformation.” Data fabrics must integrate with external solutions, manage data across all environments (multi-cloud and on-premises), support batch, real-time and big data use cases, and provide APIs to new data transformations.

Data fabrics weave a cohesive whole from multiple disparate apps and microservices, many of which are hosted by third-party vendors. As such, a data fabric should reduce the effort required to integrate new microservices or platforms, while ensuring existing systems continue to operate as normal. In this regard, data fabrics are the ultimate middleware which all other systems orbit around. Simultaneously, data fabrics are the medium for communication across complex app architectures. Whether communication via stateless REST APIs or stateful streams, data fabrics serve to ensure all microservices have the latest relevant state.

For Stateful Apps, It’s All About the APIs

Stateful microservices alone don’t make a stateful data fabric. That’s because there’s a key difference between a collection of independent stateful microservices and a cohesive stateful system. Many serverless architectures today can claim to be stateful, in the sense that stateful data processors, such as Apache Flink, can be deployed via stateless containers. However, if the primary exchange of data is stateless, such as via REST APIs, then the application itself is primarily stateless.

Deploying stateful microservices via stateless containers is not the same as a data fabric being stateful. A stateful data fabric weaves a network of stateful, streaming links between multiple persistent microservices. This allows for the creation of truly stateful apps; microservices can continuously observe data streams for critical events and peers are continuously subscribed to receive relevant updates. In other words, a stateful data fabric enables real-time, peer-to-peer (P2P) computation instead of a stateless hub-and-spoke architecture oriented around a central datastore.

The open source Swim platform is an example of a fully stateful data fabric, which leverages stateful streaming APIs to communicate across microservices. Stateful microservices (called Web Agents) can perform real-time transformations as data flows or be combined with others to create real-time aggregations. Due to the real-time nature of streaming data, each Swim microservice is guaranteed eventual state consistency with peers. However, Swim can also be configured for other delivery guarantees. Because state consistency is automatically managed by the fabric, developers are no longer on the hook for managing state across isolated microservices via REST API.

Learn More

Share your thoughts about stateful applications below and let us know what you’re building using the open-source Swim platform.

You can get started with Swim here and make sure to STAR us on GitHub.

from DZone Cloud Zone

The Kubernetes Service Mesh: A Brief Introduction to Istio

The Kubernetes Service Mesh: A Brief Introduction to Istio

Istio is an open source service mesh designed to make it easier to connect, manage, and secure traffic between, and obtain telemetry about, microservices running in containers. Istio is a collaboration between IBM, Google, and Lyft. It was originally announced in May 2017, with a 1.2 version released in June 2019.

A service mesh is not a “mesh of services.” It is a mesh of Layer 7 proxies that microservices can use to completely abstract the network away. Service meshes are designed to solve the many challenges developers face when talking to remote endpoints.

Service meshes focus narrowly on the technical issues related to establishing and maintaining reliable service-to-service connections. They do not solve for larger-scale operational issues such as inserting bulkheads, quarantining new services or exerting backpressure against a group of rogues.

As of this writing, Istio focuses mostly on Kubernetes.

Istio Architecture

Like all service meshes, an Istio service mesh consists of a data plane and a control plane.

Istio Data Plane

The Istio data plane is typically composed of Envoy proxies that are deployed as sidecars within each container on the Kubernetes pod. These proxies take on the task of establishing connections to other services and managing the communication between them.

Istio Control Plane

How this communication is managed needs to be configured, of course. Istio’s component that is responsible for configuring the data plane is called Pilot. Apart from defining basic proxy behaviors, it also allows you to specify routing rules between proxies as well as failure recovery features.

The Mixer component of Istio collects traffic metrics and can respond to various queries from the data plane such as authorization, access control or quota checks. Depending on which adapters are enabled, it can also interface with logging and monitoring systems.

Citadel is the component that allows developers to build zero-trust environments based on service identity rather than network controls. It is responsible for assigning certificates to each service and can also accept external certificate authority keys when needed.

Istio control and data plane using Envoy
Istio’s separate, centralized control plane is typically paired with Envoy as a data plane.

Why Use Istio, or Any Service Mesh for That Matter?

If you are a developer or architect looking to create a network of deployed services with built-in traffic control features, service-to-service authentication, and monitoring, all without having to make changes to your service code and you don’t mind running them on Kubernetes, then Istio is a good solution, even though it is not easy to install and requires a fair amount of knowledge of both its own and Kubernetes’ internals to troubleshoot.

Istio’s key benefits include:

  • Traffic control features including routing rules, retries, failovers, and fault injection
  • Policy enforcement including access controls, rate limits, and quotas
  • Built-in metrics, logs, and traces for all traffic within a cluster
  • Secure service-to-service communication
  • Layer 7 load balancing

Control plane features by component are given in more detail below.

Pilot: Connectivity and Communication

  • Traffic management: Istio separates traffic management from infrastructure scaling (which is handled by Kubernetes). This separation allows for features that can live outside the application code, like dynamic request routing for A/B testing, gradual rollouts, canary releases, retries, circuit breakers and fault injection.
  • Fault injection: In contrast to killing pods, delaying, or corrupting packets at the TCP layer to perform testing, Istio allows for protocol-specific fault injection into the network.
  • Layer 7 Load balancing: Istio currently supports three load balancing modes: round robin, random, and weighted least request. In contrast to Kubernetes’ own load balancing, Istio’s is based on application layer (Layer 7) and not just on transport layer (Layer 4) information.

Mixer: Monitoring and Observability

  • Backend abstraction: As mentioned previously, the Mixer component provides policy controls and telemetry collection, which abstracts away the implementation details of individual infrastructure backends.
  • Intermediation: The Mixer component also allows for fine-grained control over the interactions between Istio and databases.
  • Latency: Mixer can be used as a highly scaled and highly available second-level cache for sidecars.
  • Reliability: In some situations, Mixer could potentially help mask infrastructure backend database failures because of its caching capabilities.

Citadel: Encryption and Authentication

  • Service authentication: Services can only be accessed from strongly authenticated and authorized clients.
  • Authentication policy: Enforced only on the server side. Authentication requirements for services must be configured on the client side.
  • Role-based access control: Istio supports namespace-level, service-level and method-level access control for services.
  • TLS authentication: Istio supports both service-to-service and end-user-to-service authentication.
  • Key management: Automation of key and certificate generation, distribution, rotation and revocation.

Criticisms of Istio and Other Service Meshes

Despite their apparent popularity and promise of attractive features, service meshes are not as widely used as one would expect. This is undoubtedly due in part to their relative novelty and the fact that the general space is still evolving. However, service meshes are also not without criticisms. Typical concerns regarding Istio and service meshes include the net-new complexity they introduce, their comparatively poor performance and certain gaps with respect to multi-cluster topologies.

First, service meshes require an up-front investment in a platform that can be difficult to justify when applications are still evolving. Also, their impact on application performance when compared to direct calls across the network can be substantial and difficult to diagnose let alone remediate. Because Istio currently runs only on Kubernetes, users will have to account for the well-known performance penalty that comes when running in a containerized environment. Finally, since most service meshes target individual microservice applications, not entire landscapes of connected applications, multi-cluster, multi-region support tends not to be a focus.

In short, service meshes are no panacea for architects and operators looking to run a growing portfolio of digital services in an agile manner. They are tactical affairs that represent a “below the ground” upgrade of technical issues that predominantly interest developers. They are often not a game changer for the business.

from DZone Cloud Zone

Company Overview: Packet

Company Overview: Packet

Image title

I had the opportunity to speak with Jacob Smith, co-founder and CMO of Packet, a cloud and edge infrastructure provider based in New York City.

According to Jacob, enterprises have been moving from on-prem infrastructure to the public cloud, using more open source software solutions, leading to the adoption of containers and networking geographically-dispersed data centers.

Packet started five years ago by providing a public cloud with DevOps tools for the developer. They’ve gained early traction with software companies who understand the need to be agile, seamless, and able to scale up and down as demand changes. 

As edge computing grows, they are providing services for Sprint’s IoT initiatives in Boston, Pittsburgh, and Indianapolis — cloud consumption with a developer toolset. They’re helping DevOps with specialized hardware and are providing value around wireless. Jacob sees a lot of opportunities as 5G infrastructure builds out.

He encourages cloud-native developers to take a look at how Packet can help them at the edge with the ability to scale. Packet provides and automation platform with network connectivity and unobstructed access.

This is also beneficial for enterprises, like financial services, who are looking to moving back to a hybrid multi-cloud infrastructure after going “all-in” on the cloud and experiencing “sticker shock” who are not interested in co-located environments and don’t care what brand of servers they’re running on. 

Packet is picking up clients in the data storage business from public cloud providers who want to open geographically distributed data centers. They want the benefits of the cloud without the cost. Packet has been able to help them reduce their spend by 40 to 45% scaling infrastructure quickly for $200,000 per month versus $350,000 with automation and optimization. 

Moving forward, Jacob envisions most large enterprises evolving to an edge model where Packet will manage and maintain the operation of the infrastructure. 

from DZone Cloud Zone

Coming to Grips with Kubernetes Storage

Coming to Grips with Kubernetes Storage

Cloud storage in a compartmentalized environment is always a dark horse. It can be the simplest part of constructing a system, but it also has the potential to become very complex once your requirements grow. For data-intensive apps, storage and its scalability are key ingredients to success.

Just because you don’t run a storage-intensive app, however, it doesn’t mean you can take storage lightly. In a Kubernetes environment, storage can still be one of the most difficult things to navigate. But worry not because we are going to dig deep into Kubernetes storage in this article.

Forget About Drives

In the old days, adding storage to a server was a simple task. You added new physical hardware to the rack, mounted the new drive, and you were all set. In a corporate on-prem environment, local drives were (and still are in some cases) typically allocated for the OS only. For apps and databases though, the storage is often set from Storage Devices (Arrays) sharing logical drives to servers usually through fibre channels (Servers and Storage Arrays were connected with each other in a Storage Area Network (SAN)).

These Storage arrays are very complex and there were a lot of configurations around them, requiring specialized knowledge. From the server side, disks volumes are usually handled by volume manager software, requiring the server admin to properly configure them. In today’s cloud environment, storage is so much more straightforward in comparison. There is a lot of automation that encapsulates the complexity of what happens behind the scenes when an Admin attaches a virtual storage device to a virtual instance in the cloud.

As Kubernetes blurred the line between physical and cloud servers, storage has become something that needs to be seen from a different perspective. Disks are assigned physically but allocated logically. In traditional data centers, we also have virtual drives. There are several volume manager software in the market that creates logical volumes from a pool of physical drives. This enables efficiency in terms of space utilization and, sometimes, better performance. Containers, however, are designed to be far more robust and flexible.

Storage is also used differently depending on the kind of solution it is a part of, but this only makes managing your storage use easier. In fact, you can run two apps on two different Kube clusters, each one provisioned by a different cloud provider and still use single database storage.

Along Came Volumes

Kubernetes lets you handle storage differently, starting with using Volumes. Volumes are created to allow information stored in containers to be maintained and data is preserved across Container restarts. However, when a pod ceases to exist, the volume will cease to exist, too.

Volumes in Kubernetes are very easy to manage. It is basically a directory that gets mounted to a pod. After telling the container to use Volumes for storing evergreen information, you can safely modify the pods without ever losing your data.

Kubernetes supports a lot of volume types including awsElasticBlockStore, emptyDir, nfs, persistentVolumeClaim, configMap, and secret, to name a few of the ones you might want to take a closer look at. Check out the full list here. Almost all cloud providers offer Volumes or storage of some description. This plays to one of the real strengths of Kubernetes: its lack of hardware awareness.

Adding Persistent Volumes

Some volumes might need to outlive pods; this is not uncommon, especially with CI/CD being the process that many developers use to remain agile. This is where Persistent Volumes, or PVs, come in handy.

Persistent Volumes in Kubernetes doesn’t associate itself with one or a handful of pods. It is a resource block assigned by the administrator to the particular cluster—similar to nodes in the same cluster. Persistent Volumes acquire the details of the storage implementation whether it’s NFS, iSCSI, or a cloud-provider-specific storage system.

This means that Persistent Volumes can be used for different reasons too. Many developers use PVs for those services needing persistence, like an artifact repository. With fast storage and optimum caching, persistent storage can be the perfect solution for your needs.

Persistent Volumes are attached to nodes and pods claim a portion of this storage through PersistentVolumeClaims. Since Persistent Volumes also store data beyond the lifetime of pods, it can bridge gaps in CI/CD processes.

A Safety Layer

The final piece of the puzzle for Kubernetes storage is the Volume Snapshot. As the name suggests, Volume Snapshots are provisioned by users, but it is also designed to be compatible with dynamic provisioning if needed. The snapshot is made by Kubernetes literally taking a snapshot of the Persistent Volume in a cluster and storing it for recovery.

Don’t let the “snapshot” jargon fool you; a Volume Snapshot can actually be very big. It eats into your cloud storage allocation rather quickly. In return, though, it offers something that is invaluable, an extra safety layer for your data.

Snapshots can be restored at any point. Volume Snapshots are generated so that you can freeze other volumes in a particular state. In the more recent releases of Kubernetes, it is even possible to automate the creation (and deletion) of snapshots depending on the state of PVs as well as other parameters of the system. It does so using CSI drivers.

No Rule to Follow

There is no definite rule to follow when setting up Kubernetes storage. Remember that volumes in a pod persist upon a pod restart. They are removed only when the pod is removed from the node. Kubernetes also has StorageClass for dynamic provisioning, which means you no longer have to provision storage in a linear (and fixed) way.

StorageClass is entirely interesting on its own, too. Rather than assigning a Persistent Volume, the entire cluster can dynamically use storage in a scalable way. And dynamic provisioning means we can allocate a volume by making an API call without depending on an Administrator. With storage classes, we can define different types/classes of volumes (standard, best performance, etc.,) and the developer can use these different classes based on the app needs.

There are a lot of ways to achieve efficient Kubernetes Storage; it just all comes down to your needs and requirements. If you only need temporary storage, there is no need to create a separate AWS EBS just because you think you have to. On the other hand, storage-intensive systems need to be more serious about tackling storage-related challenges. It may seem daunting at first, but Kubernetes Storage is really not that complicated.

This post was originally published here.

from DZone Cloud Zone

Cloud-Native Best Business Practices (Part 1): Containerization Cuts Costs

Cloud-Native Best Business Practices (Part 1): Containerization Cuts Costs

To quote Michael Dell, “the cloud isn’t a place, it’s a way of doing IT.” According to the Cloud Native Computing Foundation (CNCF), in the past nine months, production cloud-native deployments — across public clouds and private data centers — have increased by over 200%. Cloud-native provides numerous benefits, but with an ever-expanding landscape of tools, projects, and providers, it can be confusing to know where to start — let along where to go.

While developers and operators can turn to the variety of resources, like StackOverflow or community Slack channels, to help them understand and implement these technologies, there are vastly fewer resources for building the business case for cloud-native computing. Without an understanding of the business case, it can be difficult for IT departments to get buy-in across departments to transition towards much-needed cloud-native computing.

Every business is premised on providing a product or service to their customers that is better, faster, cheaper, or, ideally, a combination of the three. This blog is the first of a seven-part series examining how cloud-native can help businesses deliver on their promise of better, faster, cheaper. They will cover containerization, pets vs. cattle, open source, backup and disaster recovery, API-driven programming, monitoring, and security. The goal of the series is to provide a roadmap to help teams build the business case for a cloud-native approach.

Where to Learn More

Containerization is actually the first step on the CNCF Cloud Native Trail Map. There are multiple reasons to adopt containers, including legitimate portability (better), improved developer experience, productivity, and velocity (faster), and reduced resource utilization (cheaper). From a pure P&L point of view, this last point is the most tangible.

Image title

A container is a standardized packaging of code — and all of its dependencies — that allows applications to run quickly and reliably from one environment to another. It is a further abstraction of a virtual machine (VM) (check out our blog post “Cloud Native for Non-Coders” if you want to learn or refresh the difference between a container and VM). Instead of having to virtualize everything including the kernel and OS for every application, like when using VMs, multiple applications, each in a separate container, can share the same OS. This provides many benefits tangible business benefits including isolating dependencies to create a better product, increasing delopyment speed, and reducing computing expenses. Below is a deeper dive into how containerization cuts costs.

Containerization Cuts Costs

When designing our Kubermatic Container Engine, we knew containerizing the management components of user Kubernetes clusters would reduce the overall cost of management for our customers. Using containers rather than virtual machines (VMs), like kubespray, kops, and Rancher, allows us to reduce our customer’s infrastructure costs 5x.

Below is an example cost comparison between Kubernetes cluster managed with VMs and clusters managed with containers. All pricing information is pulled from the AWS calculator.

Example Calculations

To run in production stable, high-availability mode, each user Kubernetes cluster requires three t3.medium VMs with at least 2 vCPU & 4GB RAM. Pulling pricing from the the AWS calculator Frankfurt region, each user cluster costs $105.42 per month. Thus, to run 1,000 clusters in production for a month costs $105,420 in just management overhead.

Kubermatic follows cloud-native best practices and instead uses containers to manage user Kubernetes clusters. Each Kubernetes cluster only requires 2 GB of RAM to host the containers of the control components. Thus, Kubermatic can run 1,000 clusters on only 33 m5.4xlarge VMs each with 16 vCPU & 64GB — at a total cost of only $22,223.52 per month. Using a container rather than a VM-based management model helps us reduce the cost of cluster management for our customers almost 5x.

VMs:
1 User Clusters         = 3 x VM
                                  = 3 x t3.medium
                                  = 3 x $35.14
                                  = $105.42

1,000 User Clusters  = 3000 VMs for Masters = $105,420 per month

Containers:
1 User Cluster            = 2 GB RAM
30 User Clusters        = 1 x m5.4xlarge
                                   = 1 x $ 673.44
1,000 User Cluster    = 33 VMs for Masters = $22,223.52 per month

Containerization is only the first step on the cloud-native journey and is only part of the cloud-native business case. Check out part two: Pets vs. Cattle to understand how to design a better production system.

from DZone Cloud Zone