If you are a developer or software architect you have likely heard the terms Cloud Native Computing or Cloud Native Development. There is a lot of hype (much of it deserved) around Cloud Native Computing and Applications right now. This is because Cloud Native Computing represents an advancement in the art of developing flexible, portable and scalable software. Cloud Native Development practices improve development cycle times, reduce the complexities of managing infrastructure and make building scalable applications easy and cost effective. Development teams are able to focus on delivering functionality to increase the pace of innovation.
“The big don’t eat the small anymore. The fast eat the slow.”
In this article I explain the why and how of cloud native applications by presenting the key elements of Cloud Native Application Development.
Why Cloud Native Applications
“Going cloud native will enable an organization to become a true high-performance IT organization that can win. ”
Deliver the right software, faster
In 2011 in an article written for the Wall Street Journal, Marc Andreessen, introduced the idea that “software is eating the world”. The article argued that the most companies need a high-performance IT organization to survive in this software-driven world. These high performing organizations must constantly look for ways to accelerate the delivery of new software products to meet the ever changing needs of their customers.The last two decades have seen significant improvements in both the technology and the culture of delivering the right software, faster. Cloud Native development practices are just the latest installment of these improvements.
One of the primary benefits of Cloud Native application development is the reduction development process cycle time. Cloud Native development teams are able to use automation and tooling that streamlines DevOps, Continuous Integration and Delivery (CI/CD) and testing. In addition, they do not need to deal with the complexities of infrastructure, networking or environment setup. With the proper application, Cloud Native development teams can reduce their development cycle time by 20%.
Eliminate cloud lock-in
Cloud lock-in should be a major concern for development teams. Cloud lock-in reduces your choices for development, deployment, technology and services. This reduction in choice will almost certainly lead to increased costs, development cycle times, sub-optimal technology choices or all of the above.
A key benefit of Cloud Native architecture is cloud portability and interoperability. This means that applications should be able to not only work with applications in deployed in other clouds, but be deployed in any combination to the cloud or clouds that make the most sense for a specific workload. This provides a development team with the flexibility they need to deliver software faster.
Key Elements of Cloud Native Development
Several of the major contributors to The Cloud Native Computing Foundation agree on a few foundational practices and technologies that characterize successful Cloud Native development teams.
- Development Automation
The goal of a microservice architecture pattern is to deliver self-contained software modules, or services, that represent a single business capability. These services can be individually developed, tested and deployed. By uncoupling individual capabilities in a large software application we are gaining flexibility. Each service can now be studied, improved, tested and delivered without being chained to the complexities of the larger application.
Microservices architecture is firmly rooted in the principles of Service Oriented Architecture or SOA introduced in the late 1990’s. The primary difference is in the scope of the service itself. As stated before, a microservice should represent a single, discrete business capability. An application, then, will be made up of several, if not hundreds of these microservices all working in unison to deliver a cohesive experience to the user.
Containers are the cornerstone of Cloud Native computing. To understand why you really need to understand the benefits an average developer should expect to get for using containers in the development process. The list is long, but the main advantages include:Build once, run anywhere. Your application will run inside a container. The container in turn runs on any system where the container runtime (e.g. Docker Engine) is installed. This means that there is no need to build the application for multiple types of hardware platforms or operating systems. You only have to build it once.Consistency between environments. When doing development with containers, you test your application inside the container. You then ship your application in the same container. That means the environment in which you test is identical to the one in which the application will run in production. As a result, developers can have much more confidence that end users won’t experience problems that the QA team missed when it was testing.Modularity. Doing development with containers is perfect for a microservices approach to app design. With a microservices architecture, as stated in the previous section complex applications are split into individual discrete services. Containers provide an operational decoupling for these microservices by creating a virtualization layer at the infrastructure level. This means that different modules of the application, or microservices, can be deployed and scaled independently.
No discussion of containers, however, would be complete without the discussion of container orchestration. The more containers we deploy, the more complex the environment. For example, Google deploys over 7000 containers per second. Managing the location, networking, monitoring and deployment of these containers manually would be impossible. To solve for this, Google created a layer of automation that lead to the creation of the very popular open source project Kubernetes. Kubernetes is the container orchestration engine that forms the basis of the Cloud Native Computing Foundation.
Adapting to Cloud Native architecture is not solely a technology driven change. It also requires a cultural change. In the past development teams packaged applications in large bundles, or monolithic applications, that were released twice a year or quarterly. This was done largely because the coordination of hundreds of developers coming together for the release of an agreed upon set of features was very complicated. You did not want to expend this amount of management overhead every month or every week. Over the last couple of decades, however, we have learned how to automate portions of the software delivery lifecycle. This has lead to shorter and shorter cycle times. Shorter cycle times mean that software is modified or fixed and released into production every two weeks, every day, or better yet, continuously. If the customer has a high priority fix or modification to the application they have the opportunity to see that change in a few days rather than six months.
Automating the development lifecycle also means that developers are no longer spending their time with tedious, repetitive and time consuming tasks. It is not uncommon for a developer to spend 20% of their time on tasks associated with setting up their development or test environments, managing infrastructure, or managing builds and deployments. By automating these functions or removing them through DevOps tools and development platforms, developers are able to focus on the value-add activities of developing software.
Cloud native applications help to stay ahead of your competition by enabling IT organization to deliver innovation at a faster pace in a cost-efficient way. In this article, I tried to define the top key elements for building cloud native applications. In the next articles I plan to dive deeper into each of these areas and discuss how development teams can adopt these practices.