5 things to do when going cloud-native
Tags: cloudnative, kubernetes, devops, containerapps
Published: 2023-01-16 09:27:08

Beginnings are hard. But they are less painful and way more enjoyable if you are in good company. Let us welcome you into the cloud-native world with a series of blog posts where we aim to make it easier for you to start developing cloud-native applications. You can already read an [introduction to cloud-native development](https://napptive.com/introduction-to-cloud-native-development) and [how to get started in AWS](https://napptive.com/kubernetes-on-aws-tips-and-how-to-get-started). In this article, you will find out the first 5 things to do when going cloud-native.

**What to do when you want to go cloud-native**

First of all, you need to know what cloud-native is. It is easy to fall into the trap of thinking that just moving your existing applications to a cloud makes them automatically cloud-native. Quite the opposite, cloud-native applications are defined by a set of characteristics that let them make the most of a cloud environment. As we already commented in our [introductory post](https://napptive.com/introduction-to-cloud-native-development), the Twelve-Factor App methodology is widely accepted as the design model for cloud-native applications. If we want to put it nice and short, we could say cloud-native apps are made up of a series of stateless and easily replaceable services that expose their APIs for interoperation. Thanks to technologies such as containerization and orchestration, they can be scheduled on different machines in a cluster and individually scaled up or down, according to demand.

So based on that, you can hardly make a monolithic application “cloud-native” by just installing it in an AWS EC2 instance. The work to transition legacy software into a cloud-native application is broad, meaning that you have to revise and redesign every single part of the development process. It sounds exhausting, we know. That is why we want to give you a short list of things to do when going cloud-native so that you can focus on what is really important and leave the rest for a later stage on your path. The main goal here is to achieve a smooth transition from legacy to cloud-native.


**5 Things to do when going cloud-native**

Without further ado, let’s dive into the first five things to do when going cloud-native.

1. Involve people
Migrating an application to the cloud is multidisciplinary work, so you will need to create a cross-functional team, or at least involve people from all teams: developers, DevOps, NetOps, and SecOps. This does not mean that everybody needs to know everything! You just need that each professional updates their area of expertise to include knowledge about cloud-native. It’s important that this initial team is motivated to do the work because they will be the company’s icebreaker, so to speak. This team will create the golden path for all the teams working on the following projects. They need to love what they are doing and be the cloud-native evangelists in the organization.

2. Choose wisely
Not everything fits as cloud-native. Do you remember the Twelve-Factor App model we mentioned above? We suggest you [read it](https://12factor.net/) and try to keep it in mind while selecting the application that you want to start with. Generally speaking, stateless apps are good candidates. Many web-faced applications fall in this category. On the other hand, anything heavily based on persistent data or proprietary hardware technology is a bad choice. For example, large databases usually must run on underlying vendor hardware. If you do need to access persistent data, you will have to rethink the model – store it externally and expose the data as a service.

3. Start small
As we mentioned at the beginning, cloud-native applications are made up of a series of loosely coupled microservices. You should create a specific service for each different functionality within a workload. Due to this architecture, cloud-native apps are complex. Your best bet is to start with a relatively simple, low-risk app. Add only those services that are meaningful, as each new one will increase the overall complexity. 

4. Move your CI/CD closer to the cloud
Developing and testing locally makes it difficult to emulate production conditions. This can lead to unexpected behavior and many headaches later on. Leverage containers instead – they allow the creation of cheap, disposable environments that are identical to production ones. Then, you can integrate them into a fully automated CI/CD pipeline that tests and push new code to production. This leads to faster development and easy rollbacks if necessary.

5. Observe your app
So we have said that cloud-native applications are complex a bunch of times by now. The services’ lifecycles, their interactions, their points of access… – they all pose a non-negligible amount of opportunities for failure. This is where you will find it very valuable to prepare your environment with the appropriate tools for monitoring, testing, and securing your app. Be aware that not only will you need to test the services, but also their relationships. Existing security tools were not built for this. Consider a good service mesh technology to help you out with debugging, observing, encrypting, and setting security policies for your cloud-native app.

**Conclusion**

Tempting as it could be, going cloud-native is not a task for a one-person team. Cloud-native applications are complex to design, develop, test, secure, and observe. So choose a cross-functional team of enthusiastic people to work with you. Be sure to start small with a relatively simple, stateless app that does not rely much on user data. Make use of containers and other cloud technologies in your CI/CD pipeline, and always monitor your deployed application. We hope that, by considering these five steps, you can make your cloud-native journey as painless as possible. Once you master this phase, you will be able to really enjoy all the benefits that cloud development can offer – team independence, frequent updates, reliability, scalability, reduced costs and so much more.