Introduction to cloud-native development

Cloud-native is the buzzword nowadays. All the big names are moving their services to the cloud, hirers ask for cloud-native understanding, and it looks like you’ll be out as a developer if you don’t learn cloud-native development ASAP. The problem is this is not just a new technology – Cloud computing brings a complete paradigm change. But don’t worry – we’re here to help! In this introduction to cloud-native development, we’re going to cover what it exactly is, why it is so important, the basics of cloud computing, and the key to designing cloud-native applications.

Introduction to cloud-native development

First things first – what is cloud-native? You can look for the official definition on the Cloud Native Computing Foundation (CNCF) site, but we’ll give you a simple definition here:

Cloud-native computing is a new paradigm that lets organizations build and run scalable applications on cutting-edge machines with minimum human intervention. The aim is to enable an agile development environment where new services and features go into production without delay.

These are the three pillars that make it possible:

Cloud infrastructure, where servers are no longer treated like pets but more like cattle. Workloads are distributed among several machines, and any of them can be instantly replaced if it falls.
The microservice architecture. Instead of creating a complex monolithic application, independent teams easily build and maintain loosely coupled microservices that offer the same global functionality to the end user.
Automation through tools that schedule, monitor, or push changes to production, among other chores.

Why is cloud-native important?

There is a bunch of benefits that make cloud-native development so desirable:

• Speed: In today’s rapidly changing life, speed is key. We’ve already experienced this phenomenon with food, then retail, and now it’s the time for online services. Customers expect robust, fast-moving applications and frequent updates. Organizations cannot wait for a quarterly release to fix errors and add new features anymore. Cloud-native development enables teams to work independently and deploy frequently.
• Reliability: Thanks to the new architecture, bugs in a microservice won’t cause the whole application to crash. Automating tools make it easy to roll back to a previous, stable version in no time. At a lower level, a failure in a machine won’t make the service unavailable because there will be others in the cloud serving it.
• Scalability: Service replicas are scaled up and down service dynamically, according to demand. Infrastructure is also flexible, as cloud vendors let you adjust resource usage on demand.
• Reduced cost: In public clouds, you usually pay for the resources you use. This way, you avoid having to rent or acquire over-dimensioned infrastructure. In addition, most tools are open-source, freeing you from licensing costs.
• No vendor lock-in: There’s a specific intention in the cloud-computing community to make tools interoperable. In addition, public cloud providers have adopted some of the most used open-source tools to attract more clients.
• Access to cutting-edge technology: Cloud providers are constantly updating their machines. This is something hard to do with your own servers, as it would be too costly.

So this is why many organizations are making their business logic cloud-native. However, it’s not just as simple as moving your monolith to the cloud (it’s a way to start, though). In the next section, you’ll learn what makes an application cloud-native.

Cloud-native development 101

Cloud-native applications are a case of software as a service (SaaS). Because of this, the Twelve-Factor App methodology is widely accepted for the design of cloud-native apps. Though you can read about each of the factors in the previous link, here you have a summary:

Codebase – One codebase tracked in version control, many deploys (typically a production site, staging sites, and development environments).
Dependencies – Explicitly declare dependencies in a manifest and isolate them during execution to ensure the app will run correctly anywhere, anytime.
Config – Everything that is likely to vary between deploys must be stored in environment variables, not as constants in the code.
Backing services – Treat backing services as attached resources accessed via a URL or other locator/credentials stored in the config.
Build, release, run – Strictly separate build, release, and run stages.
Processes – Execute the app as one or more stateless processes. Any data that needs to persist must be stored in a stateful backing service, typically a database.
Port binding – Export services via port binding.
Concurrency – Scale out via the Unix process model.
Disposability – Fast startup and graceful shutdown facilitate fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys.
Dev/prod parity – Keep development, staging, and production as similar as possible
Logs – Logs are the stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services. Each running process writes its event stream, unbuffered, to stdout.
Admin processes – Run admin/management tasks as one-off processes.

Many of these factors are directly guaranteed by the enabling technology, as we’re about to see in the next section.

Building blocks of cloud-native development

Now that we know how to design a cloud-native application, let’s finish this introduction to cloud-native development with a look at the technologies that make it possible:

Cloud computing: Cloud providers like AWS, Azure, and others offer computing resources on-demand over the internet. Clients can outsource some of their computing needs and focus on their services without investing time and money in infrastructure.
Infrastructure as code (IaC): The practice of storing the definition of infrastructure in a declarative form allows teams to have a single source of truth for all configurations. This lets them implement version control on the infrastructure and create deployment strategies while reducing misconfiguration errors. Terraform is a commonly used tool for defining and configuring infrastructure.
CI/CD pipelines: Continuous integration (CI) is the practice of integrating code changes to a source control system, such as Git, as regularly as possible. The CI process tests if the changes are valid. Then, the continuous deployment (CD) process automatically deploys them from test to production. Using CI/CD pipelines speed up code updates in production, allowing fast-evolving applications. Jenkins is a platform that aids in pipeline creation.
Containers: They are running microservices isolated from other processes in the same machine. The code, configuration, and dependencies are all encapsulated inside the container. The best-known containerization tool is Docker.
Container orchestration: Containers need to be scheduled on actual machines in a cloud, scaled up or down, replaced, etc. When the number of containers is significant, it can’t be done manually, so an automating tool is necessary. The most prevalent container orchestration tool is Kubernetes.
This is a brief summary of the most relevant technologies that enable cloud-native development. If you want to know more, you can click the links to read about each one or peruse the whole CNCF Glossary.

This post was originally published at Napptive