The truth behind “Application Modernization”

Are you currently considering refactoring, replatforming, or rearchitecting an application? Well congratulations because that most likely means that you’ve chosen to embark on the path to application modernization after discovering the four key benefits which the Cloud can provide.

Unlocking the benefits of cloud application modernization

These benefits to be precise: 

1. IT modernization: by reducing the technical debt from outdated hardware and software and improving the underlying infrastructure including: improved security, operations, reliability, scalability, and more. 
2. Cost savings: by reducing the amount of money spent on costly hardware and software and improving the utliziation of resources including: lower TCO or switching from CAPEX to OPEX. 
3. Business agility: by being able to react to market changes faster and improving the capacity to roll out new business initiatives to make the most of new opportunities. 
4. Innovation: by driving new value from technology and developing and releasing new products and services. 

However, even with all of these benefits to look forward to the path to application modernization isn’t always an easy one. It can often split across multiple different directions with many organizations not knowing which to take. But fear not - let us lead the way and reveal the truth about two paths which organizations frequently cross and don’t know which to take : DIY and Managed Kubernetes or the all-in-one PaaS.

The foundations and best practices for container-based application modernization

Before we dive into the best choice for application modernization today, we need to look into where it all started. Whether you decide to develop your own WebOps platform or rely on a PaaS, they both rely on the same five fundamental principles of modern engineering practices. 

Together forming a coherent set of best practices to follow for modern applications: 

1. Open-Source technologies: If you’re still not convinced on adopting OSS then check out this article from our friends at Strapi. 
2. Container-based applications: Ready to say goodbye to your development environment that reflects your production from…2016? It’s time! 
3. Microservices-ready: But remember, stacking them up over and over again will bring you right back to a monolith - so remember to keep ‘em tidy. 
4. Git-driven: There’s truly no other way to code, it’s gotta be Git. 
5. Serverless first: Simply run your code and pay-per-use. And fingers crossed you don’t have any bugs in your code.

Now. With the basic downs, it’s time to get into what it really means to lead an application modernization project with all its different stages and challenges. Allow us to lift the veil on any confusion around application modernization before we dive into those two paths we mentioned earlier.

Key steps in the application modernization approach

By shedding some light on the methodology behind application modernization, we hope you will be able to identify which step(s) present a potential risk for your team or project. Allowing you to evaluate which of the two paths (DIY or PaaS) is the most suitable for you to take knowing the full picture:

• Step 1: Assess what you have. It may seem obvious but we’ve lost count of how many times teams have discovered at the very last moment a small function or component their applications need to run that they missed out. 
• Step 2: Secure sponsorship. When a project is lead by an individual without effective transparency with their team…usually things don’t go too well. 
• Step 3: Validate automatically. No organizational siloes or middlemen between development and operations. Adopt DevOps. 
• Step 4: Design as a standard. And you might, at some point, consider a rebuild rather than a migration. 
• Step 5: Track for efficiency. We’re not talking about operations monitoring but health metrics you can check on a weekly basis in your stand-ups. 
• Step 6: Change and train. Even if you’re a DIY-person and a great self-learner when it comes to enterprise-grade deployment, it’s strongly recommended to adopt the editor’s customer success methodology. 

Got them all? Great! You’ve got everything you need to make the right decision. It’s time to dive into our two paths - DIY or PaaS - starting with the former. 

Application deployment: DIY and Managed Kubernetes

Are you willing and ready to design, build, and run your own implementation? Amazing - you’re most likely a DIY person! And like every DIY YouTube video, it starts by setting up your own workshop or as we call it in the cloud ecosystem, the landing zone. You can also view it as the foundation of your project and as a result, an unavoidable cost. 

The Landing Zone is made of various different pillars and modules that evolve with time. And while it can vary depending on whether the application is made for PoC initiatives or global enterprise workloads, there are a few key items which are required for a production environment. These are:

1. IAM and governance
2. Networking
3. Security
4. Observability
5. Shared services 
6. Billing
7. Automation 

Seems like a lot, right? In reality, a specialized agency is able to deliver a standard and production-ready setup in roughly 25 working days. That’s not including the additional time for training and documentation that would be expected with any project. 

Now, let’s assume that your goal is to deploy Kubernetes, even though it relies on Managed Services like Google Kubernetes Engine or Azure Kubernetes Service. Unfortunately, certain features don’t work by magic. For example, Autopilot or Auto-scaling work really well…once you have the proper configuration, that is. 

To deploy a Kubernetes-based application, the initial landing zone we mentioned earlier needs to have some modules adapted including network, security, observability, shared services, and automation. As well as a new key module created: the Kubernetes architecture. 

Fine, but what does that mean exactly? Well, you’ll have to consider things like the isolation strategy, the high-availability, the node pools settings, the label settings, the workloads classifications, the LimitRange and quotas settings, etcd encryption configuration, Pod Security Policies and Security Context, and the list goes on. 

A list that will need about 15 additional working days to work through meaning a total of 40 working days for a landing zone set up if you add in those 25 days from earlier. A minimum initial investment which should always be considered before embarking on a DIY strategy - especially in the long-term. And remember, it’s DIY which means that every time a new use case emerges, you’ll have to do it yourself again and maintain what you’ve already created for the foreseeable. 

When it comes to DIY and Managed Kubernetes you should always ask yourself: what is the true purpose here? Most developers don’t take up their role to engineer custom platforms and even major companies have failed at doing so. But that’s precisely why Platform-as-a-Service (PaaS) solutions were created. 

The all-in-one PaaS advantage for application development

At this point in the article you’re probably thought to yourself “yeah, they’re right about DIY but…” or “hmm but what if…” and we hope you’ve done exactly that! It means that like the majority of other people, you want to see the full map before you take a new path for your next project. Ensuring that a PaaS is flexible enough to meet your project and development needs and getting answers for questions like: 

• Can I switch from AWS to GCP? 
• Can I host my application in France and not in Germany?
• Can I migrate away from ElasticSearch to OpenSearch?
• Can I develop in Node instead of PHP?
• Can I build an independent middleware?
• Can I build a new microservice-architecture application?
• …and no doubt, many more. 

We get it, people need reassurance that a new path is going to lead somewhere better. And in many cases, we can all have some difficulty when letting go of some responsibilities on our projects. But if you can move beyond those concerns, then you can welcome yourself to the world of PaaS and embrace an easier road to development. 

The concept of PaaS is a pretty attractive one - you focus on delivering the code while the provider manages everything else. Sounds good, right? No need to build a landing zone or anything else for that matter. And it all works in a declarative manner, just tell the provider what you want (usually in a YAML config. file), redeploy, and it’s usually yours. All while having the freedom to do a bit of customization or use external tools to bolster your application where wanted or needed. 

PaaS really is a foolproof way of standardizing your infrastructure but it’s no secret that standardization can come at a cost. A higher cost which for us, delivers greater benefits. 

When scouring the market for the best PaaS you should pay attention to attributes like: the platform’s dependency to the underlying IaaS providers and the localization available, the bring-your-own tool policy (like a CDN), and the set of supported runtimes they offer. You should also take a look at the history of the platform provider as it can reveal a lot about the philosophy and purpose of the solution they are providing. There’s a huge difference between an engineer who built a product to solve their former pain points and an entrepreneur who wanted to jump on a market opportunity. But there a plenty of PaaS providers who can provide you with it all.

The greener path for application modernization

Imagine - you’ve decided it’s time to modernize your application, you already adopted the best practices we discussed earlier and have designed a methodology to make it happen. That means there’s only one question left unanswered: do I go solo or PaaS? 

That’s something only you can decide, but if you want our opinion on the matter - we think that PaaS is looking greener with us.