Cloud Native Apps vs. Traditional Enterprise Apps

If I were to guess I’d say that there is no person in the world that hasn’t heard about the word CLOUD. And I do not mean those white objects in the sky. The thing is that far less people actually understand the true meaning of this word when it comes to tech. In this article I’ll not dive into that particular area – instead, I’ll focus on comparing cloud-native apps with traditional enterprise applications.

So before we begin we should understand those two concepts, so we’re fully aware of what we’re actually comparing.

Traditional Enterprise Applications

This type of applications is old-school monolith-type. They were usually done using waterfall methodologies (or some sluggish attempts of SCRUM) and are connected heavily to hardware and software that was used while deploying them for the first time. They are heavily OS-dependent, require physical resources that are not easily scalable and even if the engineers are using microservices for some parts, they are still being deployed in a monolith style. Further development of those applications is usually taking more time and (obviously) costs way more. Scalability also requires more time and cannot be changed on an “on-need” basis. Their popularity was pretty high around 10-20 years ago when cloud services were almost non-existent – one must also remember that the IT industry scene was way smaller and the capital was focused around a considerably low amount of key players. The importance of this fact will be dealt with later on in this article 🙂

Cloud Native Applications

This term describes applications that rely on many advantages of cloud computing and are built based on microservices architecture. It’s important to bear in mind that cloud-native development of applications is an idea that describes how they are created, maintained and optimised. That doesn’t necessarily mean that they are stored in the cloud – on the contrary – they can be stored on premises, yet still benefit from the cloud-native approach. This is important especially for the highly regulated markets.

Those types of applications are also benefiting from CI (continuous integration) and CD (continuous deployment) solutions.

To confuse us even a bit more, there is also a concept of cloud-enabled applications. Those are usually describing a traditional enterprise application that was moved to the cloud. It still represents a lot of the drawbacks of their predecessors. In this article, we will not focus much on those, but I just wanted to mention them to give you a full picture.

Drawbacks of Traditional Enterprise Applications

In this article I’m (probably you can see it already) promoting the idea of cloud-native apps, so I’m going to focus on the drawbacks of the old-school approach. It doesn’t mean there are no upsides, but I simply do not see much point in describing them. If you feel that something was missed in this respect – do not hesitate to comment or write to me directly, I’d gladly talk about it.

The biggest drawback of Traditional Enterprise Applications apps is a monolith environment, which very often requires a waterfall-like approach to any new features or changes in existing ones. Quite often their test environment is far different from the production one, which increases the chances of critical problems after deployment.

Because of being heavily hardware and OS-dependent, it’s really hard to migrate or scale them, which (I guess it’s pretty obvious) generates a lot of development costs and takes quite a large amount of precious time. Also, while speaking of scaling, we must point out that Traditional Enterprise Applications are built based on predicted traffic. Hence it’s impossible to manage any situation that creates spikes exceeding those assumed limits (we also must remember that those apps were created while the internet was considerably smaller).

They also tend to have limited and hard to follow backup and recovery procedures.

As you can see this approach has pretty serious consequences that heavily impact the business. As I mentioned before, 20 years ago all those factors were not that important as the industry looked much different than today. Now the time to market is essential, as well as maintainability and team morale. Choosing this way will make it almost impossible to stay competitive and provide the quality and standards required by the clients.

Why cloud-native apps is (most probably) the best way to go

One of the most interesting features of benefiting from the cloud-native approach is the possibility of moving even old, monolith applications into the cloud (through Docker-like approach). This way docker (or other tools) provides us with the legacy environment while allowing us to use the network solutions available to the cloud. It also creates the possibility of slowly changing the legacy architecture into a cloud-native one, like microservices and then slowly phasing out the legacy solution.

I decided to start off with his benefit because it gives hope to those stuck in the IT-ancient times:)

But going back to the benefits – being able to fully abstract the app from the OS or the hardware itself gives us endless possibilities. It allows engineers to focus on doing their actual job, rather than fighting with hardware and software dependencies that are not up to them. This new abstract layer just makes everything so much easier and, guess what, faster.

When it comes to hardware capabilities cloud-native approach gives the engineers full control and the ability to scale up and down whenever necessary. It’s easy and efficient, allowing your customers to gain benefits from your software no matter the traffic. Your business, on the other hand, gains better cost control over pricy resources, making sure that you only pay for what you actually need. It also gives us much better control over the deployment process itself, reducing risks and the number of critical problems.

The teamwork itself in this type of organisation is also way easier. Teams can be easily divided into smaller organisations that take care of particular services or areas (like security). Usage of proper tools allows them also to cooperate with each other, even though they do not work on the same parts. Besides that they also benefit from continuous integration that keeps an eye on the code quality, making sure that whatever gets deployed, maintains some level of quality and security.

Last, but not least, one must also look at the backup and recovery options that are available. This makes the whole environment more secure and efficient for their clients, allowing them to keep downtimes to a minimum. And we all know that each incident can cost a lot of money (you can easily see the correlation between stock prices and incidents for large tech companies).

So what’s the verdict

Well, I guess you may say it’s pretty obvious. To be honest I truly don’t want to say that one solution is the best way to go. But in this case, it’s really hard for me to find some arguments that would call in favour of the traditional enterprise apps approach. Whenever I need to make some technical decision I always try to think about the business side first. And with cloud-native apps the business side benefits so much that it’s hard to argue. The speed, the open collaborative environment, safety, maintainability, scalability and security. All those factors seem to be shouting loudly “pick me”. If you feel that despite all those facts there is a case where the traditional approach is better, please drop me a line – I’d be happy to include your thoughts in this article:)

And one final thought – I strongly encourage you to always think about the business side when making any technological decisions.