Hopefully you had an opportunity to read my previous article in which I covered the difference between cloud native and traditional enterprise apps. If not - I strongly encourage you to do so, as it will lay a very good groundwork for this one. Here I will not focus so much on explaining the cloud native apps traits, but rather would focus on basic principles that should be followed and tools to be used when creating one.
Basic information about cloud native apps
Even though I explained it in the previous article, I feel it's important to remind ourselves what we should remember about cloud native apps.
The most important thing is that cloud native apps are not really dependent on cloud services. On the contrary - cloud native apps are OS-independent and hardware-independent. So basically they can be run both on cloud as well as old-school servers.
Cloud native apps are basically the best answer for the current IT requirements - fast delivery, high quality, maintainability and infrastructure independence. It may seem a bit foggy for people that did not have any experience with app-development, so let me get to specific tools/methodologies that make cloud-native apps what they are - this will definitely shed more light on the concept.
Business as the core value
First thing that we need to understand is that when it comes to building cloud native apps there is one important thing - business should be treated as the core value. All other aspects are actually merely an expansion of this value. The landscape of current software companies is way different than it used to be. The time-to-market combined with quality is now the most important aspect and, as you can remember from the previous article, the old way of building products (we call it enterprise applications) simply cannot accommodate it. Cloud native applications are simply the only answer in fast-changing and dynamic environments. It creates much more business value in a shorter time, maintaining relatively high quality of the technical aspects. Having that in mind, let's analyze the key factors that make them what they are.
The way people used to build apps a few years ago was called monolith architecture. Application was built as one big product and also deployed as such. I will not dig into the problems that derived from this approach, but rather focus on the way cloud native solves them :) The answer is microservices architecture - which basically divides a large application into small, pretty independent, parts. This means that if you change one part of the system you can easily deploy those changes without worrying or even notifying the rest of the development team. This is a huge speed improvement if you compare it to monolith apps. What's even more interesting is that the development team can be divided into groups, allowing each group to handle specific microservice - so you can have for example a group of engineers that take care of the payment system only. This allows them to specialize in a narrow field, making the development process even faster and more efficient.
Another important aspect of microservices is a smaller time required to deploy - that means IT can react much quicker to any issues - as only the selected services can be deployed.
Another obvious fact is - the testing of the application also gets simplified - as you need to test a given part of the app, rather than the whole, everytime you make changes.
Last, but not least, you can easily use different programming languages for specific microservices - this way you can take advantage of a given language according to what it actually needs to do. This usually doesn't mean that each microservice is done in another language, but it is possible to use for ex. GO Lang for a part of the system that requires very high speed or python for AI/data - related features.
At this point you may ask yourself a question: what makes it possible for those microservices to work together - answer is pretty simple - API driven development. We will cover that later on:)
As you can clearly see from the previous chapter, devops may pose a lot of challenges simply because the deployments ideally would be done more often and should take less time without threatening other parts of the application.
The idea is to shorten the time between developing features and deploying them to production. It's also important to allow the QA department to test new features easily - ideally with data as close to production data as possible. Devops used to be very much disconnected from programmers - but now this is changing. Devops is becoming more and more integrated into the programmer's world, mostly because it's becoming less complicated and more automated. There are a lot of tools that allow for this to happen.
What is also very important is that a new approach to devops allows to monitor the traffic and adjust the servers to the requirements - to put it simply - more traffic equals more backend power. This is a huge upgrade compared to the old ways where the servers needed to be configured and purchased according to predicted traffic - and we all know at least a few examples where applications became inoperable because of sudden spikes. Now it doesn't happen that often - mainly because of the devops tools being integrated with backend parts of the system.
Devops also became more integrated with the quality assurance process but we will cover that in more detail in further paragraphs.
As mentioned in the first chapter API driven development is what allows microservices architecture to work in the way it's supposed to and bring the business values mentioned.
API driven approach allows certain parts of the application to communicate and exchange data. Currently it also allows the frontend part of the application (and mobile applications as well) to work seamlessly with the backend part of the system. It heavily decreases the amount of work, as you simply need just one backend app to cover both mobile and desktop - the only thing that differs is the interface, but since it communicates through RESTFUL API you do not really need to worry about it (as a backend developer). You simply create your part in a way that API documentation describes it.
It all seems pretty straightforward but still there are some small (or not) aspects that development teams should be aware of.
The most important aspect is - surprise surprise - efficiency:) When building any API you have to remember that it has to be able to manage varying loads of traffic (and I'm not even mentioning DOS attacks). To be able to do so the engineer should consider caching of the most used and not-so-often updated part of data, but also to cover the edge case when API is taking much longer to answer than expected. This isn't rocket science but it is of vital importance when designing the architecture. Additionally the new approach to devops makes it easier to monitor traffic and down/up scale the server when needed, without having to wait for new machines to be put in place (as it was in the old days). This also makes cloud native apps cost-effective - and everybody loves that.
The other - very important - aspect that absolutely must be considered is API versioning. This is especially vital when we have different versions of mobile apps currently in use. As the web apps usually rely simply on what the server serves the user it's easier, but mobile apps can exist with many different versions at the same time. Having different API versions also makes it easier to test new features or give early beta access to some of them.
As mentioned before, cloud native application development should always have business goals put in the first place. That is why testing aka quality assurance should be treated with high priority. In the old days it was way harder to test - because of lack of microservices the applications were deployed as a whole and had to be tested as such. I don't think I need to explain why this was problematic:) So let's take a look at the current situation.
First of all because of the microservices architecture and API driven development the amount of work that needs to be done is smaller as we are mainly focusing on the microservice at hand.
But what is even more important is how the DevOps part contributes to quality assurance.
Because of CI/CD (continuous integration and continuous delivery) there is a lot that the programmers can do in order to minimise the risk of unknown errors. Integration tests also speed up the process, as they can very quickly check if the microservice is working properly with the other parts of the system. DevOps also heavily enhances the stress testing of the app, making sure that it will withstand the spikes in traffic with ease.
Another aspect that is much more efficient than it used to be is client testing - and again, it's the devops that contributes here. The testing environment with data copied and even anonymised automatically is now possible and doesn't need much effort from the engineers. A well tested, documented and maintained application that is easy to deploy and has fast delivery times is the key in the current IT world.
Cloud native applications most important features
Now that we have covered a few of the main traits of cloud native application we can try to summarise it with some of the most important features of this approach.
If I were to choose the most important one I'd definitely go with maintainability.
As you can see it's so much easier to expand and maintain the codebase compared to old ways of doing things. Those types of apps are way less prone to downtimes and complete shutdowns. Worst case scenario there could be small problems with particular features BUT when the API mechanisms are well maintained it's easy to give the end user very precise feedback and also alert the team that handles particular parts of the system. Integration tests also help to see if any change will work well with the rest of the system.
The other important feature is scalability. Thanks to devops tools it's possible to scale the app or particular part easily - either up or down. This helps to reduce server costs, but also gives the users way better experience with our product.
I already mentioned monitoring for errors, but I will point it out again - the cloud native approach is very integrated with proper logging and monitoring. This makes it all much more bulletproof and secure, as we can very easily track what is happening with the system - allowing the IT department to react quickly to any problems that may arise and deploy changes on the go - as we're using microservices architecture. The deployment process itself used to take so much longer than it takes now.
As we can see cloud native app development does not specifically mean that it needs to be cloud-based. It's more about architectural decisions and engineering approach. It also heavily depends on the culture within the organisation as the IT department needs to be much more immersed in business perspective allowing them to understand what they are really doing and reacting quickly to the market needs. The cloud landscape is growing everyday, I can strongly recommend you to visit this website - CNCF Cloud Native Interactive Landscape to see how many tools and techniques are available. It's pretty hard to cover everything in one article - hence if you feel like I missed something truly important do not hesitate to drop me a line - I'd be happy to include your thoughts in future edits of this article or its new version - as I have no doubt there will be more. Cloud native applications is a topic relatively new to the scene and I'm sure we are yet to see some exciting solutions here.
If you need additional information about cloud native app, check the following article: