This is the first post in a four-part blog series on cloud-native applications that aims to provide a better understanding of what cloud-native applications are and how to fully exploit the benefits of this new architecture.
In this introductory post, we’ll cover some of the advantages of cloud-native apps, drivers behind it and discuss some of the challenges you should be aware of when building cloud-native applications.
Many organizations are now shifting to a cloud-native approach in combination with microservices architecture and container technologies to accelerate innovation and take advantage of the higher scalability, flexibility, and speed that the technology offers.
To give us an overview about cloud-native applications, we sat down with one of our Directors of Engineering, Chris Lim, to talk about the emergence of cloud-native architecture, its benefits and challenges, and some considerations in adopting this approach.
Q. There’s a growing buzz in the past 2-3 years about Microservices, containerization of applications and Devops around Kubernetes. What is it all about? And how do Microservices and Kubernetes play in this concept?
Chris Lim: The traditional way of software application development is to have a single deployable unit that contains all the features of the application. This is also called monolithic architecture. So for example, we have created a Healthcare Information System which includes the billing, admission, nursing, pharmacy and other modules — all of these components are bundled together and deployed as a single deployable unit. This kind of architecture has its trade-offs. For one, it is relatively easier to develop as developers are dealing with a single set of source codes and popular IDEs support this. Another is that it easier to deploy and scale as we are dealing with a singular deployment unit. However, the disadvantages of monolithic architecture overshadow its advantages over the long term. A large code base is not easy to maintain and intimidates developers. Introducing a code change may introduce bugs on other parts of the application. Over time the size of the deployment unit grows and overloads the server. In order to fix a bug or implement an enhancement to one component means redeploying the whole application. This means some production downtime and interruption in the business operation. Depending on the size, technologies and process used, deploying an update is very time-consuming and the whole cycle will have to be repeated with every change. In systems that can’t afford a downtime such as healthcare, production deployment is a very risky business. Scalability in a monolithic application is also another area of major concern. Multiple copies of the application have to be deployed to cater to an increased transaction volume. This is not a very efficient configuration. Different application components have different resource requirements. A component may be CPU intensive and another component might be memory intensive. The total resources have to be taken into consideration in planning for server capacity. There is no way to scale components individually.
Cloud-native application architecture aims to solve the limitations of the monolithic application architecture. Microservice is about designing the software such that the components are broken down into separate deployable units. Component separation is usually around functional boundaries. So going back to our Hospital Information System example, components would be the billing, admission, nursing modules. These will become separate deployable units. Imagine for a moment that there is a surge in patient admission stretching the computing resources for the admission module. In a monolithic environment, this is a big issue as probably the whole application is experiencing a slowdown at this point. In a cloud-native environment however it is a different story. Other components of the application continue to function as normal. What the operations team needs to do is to scale the admission module to 3 or 4 or 5 depending on the load. Another option is for the operations team to define an autoscale policy. Without human intervention, the system will self-heal itself. Scaling up when more resources are needed and scaling back down when demand is low.
Kubernetes serves as the platform in which the microservice components are deployed. It is responsible for the deployment, scaling, maintenance, scheduling and operation of multiple application components.
These tasks will be very tedious if performed manually. Automation tools and practices exist to streamline the process of coding, testing, integration, deployment and infrastructure management. To coin a single term for all this — DevOps. It helps to improve efficiency in the software development lifecycle.
Q: What are the advantages of cloud-native applications?
Chris Lim: One of the benefits of a cloud-native application is its scalability and flexibility — the ability to change or add new features without putting down the whole system or application and disrupting your operations.
The distributed nature of cloud-native applications provide the benefits of scalability and overall higher system availability. Because the system is distributed, cloud-native apps are more robust, highly fault-tolerant and remove the single-point-of-failure.
A cloud-native architecture enables flexible and agile development, shorter development cycles, and quicker time to deployment.
Combining agile techniques and DevOps philosophies such as continuous delivery in cloud-native patterns, you can reduce development cycles to short sprints and incorporate small, incremental changes into an application on a frequent and regular basis thus increasing your time to market while reducing your development cost.
Q: What are the challenges of cloud-native applications?
Chris Lim: Cloud-native architecture is no silver bullet. One of the challenges lies in managing the complexity of the system. Since it is distributed in nature, there is an inherent challenge in maintaining the system like handling network latency, inter-component communication, and handling multiple data store.
Since you have a lot of moving parts, another challenge is on monitoring. It is not practical to monitor each component separately so there needs to be a centralized monitoring application to monitor the whole cluster.
Challenge in troubleshooting is another one. Microservices architecture is a little more complex compared with monolithic, which makes isolating and debugging performance problems much harder.
And lastly, deploying a cloud-native app with a microservices‑architecture is also much more complex. The testing and deployment process should be robust and seamless because it is not that simple to rollback the deployed component to a previous version if something bad does get deployed.
Q: What would be the parameters enterprises should take into consideration in shifting to cloud-native architecture?
Chris Lim: From my perspective, enterprises should consider moving to microservice architecture or into cloud-native application in general if they think that they can no longer scale their business or application to the point that they are losing their business. But more than the application itself, I think it’s equally important for enterprises to consider building the capability first or getting a team with the right skills and expertise who will develop and govern the architecture.
Because embracing cloud-native applications is not just about a technological shift. It is also about a shift in an organization’s deep-rooted mindset and culture. We have to change the way we think about developing and deploying applications. It requires us to develop whole new mindsets, ways of working together, communicating with the team and practicing new design patterns.
Stay tuned for the next three parts of the series.The next post will look into how microservices and containers play together and what role container orchestration tools such as Kubernetes play in a cloud-native architecture.
About Chris Lim
Chris Lim is an engineering and technology leader with over 15 years of experience building software for the enterprise. He is passionate about empowering teams to bring innovation and build enterprise solutions that delight customers. He has a proven track record of delivering business results, successful project implementations that involve cross-functional teams and driving continuous process improvement.