Attainable Cloud Transformation for the Enterprise in 2022

Introduction

Whether you’re on the business side or the technical side of things – when you look to your peers in the industry, it seems like everyone is moving to the cloud. It’s only natural to want to emulate their success, even when you know that moving to the cloud comes with its own set of struggles. Whether large or small, cloud transformation presents its own set of challenges, but in this article, we’ll discuss some of the strategies that you can use to achieve a positive cloud transformation from traditional on-prem enterprise applications.

Why should we move to the cloud?

I don’t want to spend a lot of time here, but the main drivers should include:

Accelerate delivery

By being in the cloud, your adoption of new technologies enhances. This domino effect to promote new practices and patterns for solution delivery also enhances. This results in deploying more frequently, reducing lead time to delivery, and improving upon your mean time to recovery. (FYI – These are 3 of the 4 critical DevOps metrics).

Increase reliability and availability

By thinking of the cloud (and multiple cloud providers) as an extension of your data centers, you can achieve an unprecedented level of reliability and availability. Running your applications across the globe to reduce latency while not enlarging an infrastructure overhead is a monumental win. You have much more control to scale up and down in different regions and can leverage multi-availability zone, multi-region, and multi-cloud provider deployments to be as robust as possible.

Reduce and manage spend

See above. Going global no longer comes with the extreme infrastructure overhead it once had. Scaling up and down as necessary gives you the flexibility to respond to unexpected (but welcomed) traffic and volume while minimizing costs during off-peak periods. The budgeting and estimating practice can be narrowed significantly to avoid the burden of 5 and 10-year planning cycles across the organization.

Improve upon security practices

This is the biggest misconception when it comes to the cloud – it’s less secure. One of the greatest hurdles enterprises faces is that they’ve grown accustomed to the restrictions of an on-prem environment. Simply because it’s “closed off to the world,” it allows less secure patterns to slip through the cracks. Existing in the cloud allows you to benefit from real-time monitoring and scanning, and coupled with the Accelerate Delivery point above, you can more readily address zero-day vulnerabilities that traditionally take longer on-prem.

---

Those are just a few. The real purpose of this article is the “how”:

So, how do on-prem solutions move to the cloud, and how do we understand the beast before we try to tame it?

The answer: like any big problem, you break it down into smaller, more manageable pieces. Monoliths aren’t inherently all bad, but to gain real success in the cloud, you’ll need to take it one step at a time.

Breaking monoliths down into smaller pieces, when done correctly, could address a handful of problems by:

• Improving security
• Reducing costs
• Increasing performance

… among others.

However, you should seek to understand the individual steps of not only the process, but also the cultural shift, mindset changes, and the required effort of getting buy-in from your team and leadership.

It’s important to identify these gaps and limitations early in your process to align your team members, making the entire process a lot smoother as it progresses. A cultural shift alone doesn’t happen overnight. It’s also not something that will be successful if there are key adversaries to the change. Instead of dismissing their opinions, try to understand them. Try to break them down. For example, a comment such as “microservices is just a fad” isn’t really constructive. It’s an opinion, but what’s it based on? Fear of the unknown? Wasted efforts? It may sound daunting to understand these perspectives, but just like the technical challenge that lies ahead, break down the cultural challenge one colleague at a time.

But today – the real focus is the technical challenge because when it’s solved, the cultural challenge will sometimes occur very naturally if you demonstrate your achievements.

Effort and Strategy

If you have an existing on-prem monolith, the best way to deliver it in a cloud-first mentality is by breaking it down into smaller pieces.

Some questions to ask yourself to begin the breakdown process:

• Are there areas of the platform that can be read-only?
• Are there areas of the program that can be carved out into individual microservices?
• Are there areas of the platform that can be treated as UI only (as a fragment of the application that connects back to your on-prem environment)?

By carving out specific areas of the application, your organization minimizes risk. This is achieved by separating the old from the new, but having minimized access between them. This process ensures that there’s only one door in and one door out when it comes to protecting your data.

It’s vital to note that moving to the cloud doesn’t increase your exposure. For example, a UI is accessed by a person on-prem, and a UI accessed on cloud are no different in terms of exposure. The difference may be that your UI is accessing data from an API that is traditionally on-prem and not exposed. Limiting this exposure to a single-entry point to the API from the cloud via a secured network path mitigates the new exposure your organization undertakes.

Read-only pieces

One reliable strategy to mitigate efforts and concerns with a cloud transformation is to deploy a small, read-only area of the application in your new cloud infrastructure. This method is beneficial because it keeps the initial footprint of the application incredibly small. Your first journey into the cloud exposes a lot of new terms and technologies, so keeping the known footprint more manageable allows your comfort and confidence to grow. Over a couple of months, through exposure, you will understand “hidden” costs with the cloud (ones that often get overlooked during budgeting) and get to the first success point of running in the cloud. Starting with a read-only component, you also introduce limited concerns from security and initial efforts to achieve your first success.

Application fragments

Like the read-only model, focusing on application fragments requires carving out a specific piece of the application. One area to consider is a component that’s due for refactoring (due to security improvements or performance benefits, for instance). There could be another external justification for an application fragment to be refactored as well, but this effort can fulfill two purposes if planned for the cloud accordingly.

A good example of application fragments to separate would be things like Reporting, User Management, or operational components. Since these are naturally developed with a microservice architecture in mind, they can reduce the time to success.

Whatever your reason, your organization can leverage the time and energy used for refactoring to rethink application architecture and your overall approach to cloud-native features to deploy those features onto the cloud.

New features/services

You can also extend upon your existing monolith by adding new features and/or services. These new features are born and live solely in the cloud. They are an extension of your on-prem solution.

If you’re apprehensive about carving microservices out of your monolith or “taking away” from your monolith, this approach might be best for you. This method allows you to envision microservices as an extension, steering your process away from the classic “lift and shift.”

One of the greatest advantages of this method is its cost-effectiveness. You’re not incurring double costs because while you’re scaling up your cloud platform, you’re also scaling down on your on-prem environment. You’re also able to realize some of the efficiency benefits and can easily compare and contrast the development contributions that may still be occurring to the monolith in parallel.

As you continue to add new features to your cloud, your organization ends up with a balanced application. Eventually, you might not even have anything left over on-prem.

Goodbye, lift and shift. Hello, cost-effective baby steps.

Mindset and Mentality

Cloud transformation isn’t just a list of technical to-dos. It also requires a shift in mindset and mentality. As you embrace the cloud, it’s important to consider how your organization’s mindset will need to transform as well. You and your organization may have hesitancies due to:

• Past failures
• Cultural shifts (due to factors like a changing deployment pattern)
• Increased focus on automation (and the uncertainties of new technologies)

These hesitancies are normal. This is your sign to shake off the imposter syndrome and focus on developing your approach of carving microservices out of your monolith. Even undertaking something like infrastructure as code can be daunting.

That’s why starting small during your transition to the cloud should always be your guiding principle. Starting small allows you to get the right practices in place before you embark on a greater project.

Cloud Specifics, Cloud Agnostic, and Microservices

There are a few different ways of approaching the monolith. Splitting it up, one block at a time, results in a slow but smooth transition, making it the ideal approach for microservices.

During this process, you can leverage cloud-native services (VM on-prem to EC2 mixed with an RDS database, for instance) to improve speed, performance, and manageability. Investing in cloud-native technology, even if you end up switching clouds later, will mitigate the overall effort involved in switching clouds if you implement infrastructure as code into your workflow.

As you know, all clouds have standard features like:

• Virtual machines
• Relational database management systems
• Object storage

… among other core features.

However, some cloud providers have more specific services. For instance, AWS features “Kendra” – an intelligent search service powered by machine learning. The deeper you get into each provider, the more benefits you can reap. Of course, you don’t have to dive into the deep end on your first day at the pool.

Let’s Get to It

To ensure your success, your organization needs to constantly iterate, iterate, and iterate. To do this, build a feedback process into your cloud usage plan that focuses on the metrics like:

• Effort
• Performance
• Time to delivery

Additionally, you may need to include more specific DevOps metrics like:

• MTTR (Mean time to recovery)
• Lead time for changes
• Change failure rate
• Deployment frequency

Cost

Your organization should focus on iterative cost analysis. You want to be sure you’re avoiding a cloud bill that is 10 times the expected or worse yet, eclipses your on-prem spend. Attributing ownership of resources to a particular area of the solution can help you stay on top of this. Allocating an owner whose performance is based on optimal use of the cloud (not just keeping the bill as small as possible) is a great investment over time. Concepts of reserved instance purchasing vs spot instances, optimal sizing, and automatic shutdown/penny pinchers are just a few places to start to avoid waste. But be sure these efforts don’t negatively impact your metrics listed above!

Performance

When it comes to performance, reliability and robustness must stay top of mind. Think about how you’ve set up your alerting and monitoring systems on the cloud compared to an on-prem environment.

What does the impact of a major outage look like on the cloud?

• Who is responsible?
• What are your confidence levels?
• What are your stress levels?

If you’ve worked through a major outage on-prem, you can feel the urgency within the atmosphere. On-prem requires an “all hands on deck” attitude that will slowly shift during your transformation to the cloud. On the cloud, responsibilities change. The stress levels decrease, but that can have an adverse effect of leaving you feeling helpless. Instead, plan your infrastructure around outages and work toward being even more highly available than you already are. Again – via small, iterative changes.

Final Thoughts

With these various factors in mind, it’s clear that your organization’s cloud transformation will be a journey rather than a destination or anything that resembles a small project. If you can remedy cultural pushback and address potential challenges early, taming the monolith becomes an adventure, not a task, on your way to increased cloud adoption.

---

Indellient is a Software Development Company that specializes in Data Analytics, Cloud Services, and DevOps Services.

If your organization needs help with getting started (or tried and is now running into roadblocks), get in touch with our team to see how we can help you attain cloud transformation.

---