Gartner forecasts that spending on public cloud services will be roughly $397.5 billion in 2022, with $145.3 billion of that being on SaaS companies in particular. This should show you how powerful cloud computing is.
Yet it’s understandable to be reluctant to migrate your data center to a cloud architecture. There’s a lot of uncertainty in making the move, and unless you’re already experienced with the cloud you might not know whether it’s the right choice for your company.
That’s why today we here at Aimably are going to run down everything you need to know when considering migrating to cloud computing. We’ll cover:
- Isn’t my existing architecture good enough?
- What makes cloud architecture unique?
- Cloud architecture techniques
- When is it worth investing in cloud architecture?
- When is it not worth the investment?
- Pitfalls of cloud architecture to avoid
Let’s start migrating.
Isn’t my existing architecture good enough?
It’s entirely possible to migrate your data center to the public cloud without changing anything to be cloud-native (what’s called “rearchitecting”). The problem is that your current architecture, while functional is in no way suited to that environment or the tasks that it will perform there.
Picture this; you’re a professional cyclist. You’ve won the Tour de France several times, you’re at the peak of your fitness, and your bike is the absolute best road model on the market.
You’re also bored of winning all the time.
You aren’t satisfied with road biking - you want to prove that you’re the greatest person on two wheels there’s ever been! So, you enter into the Silk Road Mountain Race…
… And don’t even finish. In fact, you’re lucky to escape without major injury. Your bike is wrecked, the mental fatigue of harsh riding and having to carry your equipment over obstacles is overwhelming, and your nutrition plan is entirely inadequate. You didn’t appreciate the difference in preparation for the different types of races.
This is exactly what you’re doing if you try to migrate to a public cloud model without changing your software architecture.
Sure, everything might work but being on the cloud brings unique benefits that you won’t make use of and drawbacks that you’ll be hit by on top of the drawbacks of your architecture not performing as intended on the cloud.
You’ll be cycling, but using a road bike across fields with no other suitable preparation.
Instead you need to plan your infrastructure and architecture for the public cloud before you begin to make the move. That way you’ll be more certain that your software will work as intended when you shift it to the cloud, and you can immediately take advantage of the benefits that being on the cloud brings.
But in order to plan what your architecture will look like you first need to know what makes cloud architecture unique…
What makes cloud architecture unique?
First up, resources don’t have to be purchased and used until they expire. On the cloud they can be used briefly then discarded, giving you much greater flexibility in your architecture and operations.
You’re not the one buying, setting up, maintaining and storing your servers, so you can simply request more resources when you need them and just as quickly reduce your spending by paying for less.
Speaking of setting up servers, cloud resources can be purchased with pre-configured native services that can provide additional value on top of computing functionality. The resources you buy to use can come pre-packaged ready to go with features you wouldn’t have even been able to employ in a data center.
In other words, you can benefit from the hard work others have done to make their cloud resource models as efficient and effective as possible without having to put in that same work.
Cloud resources are also pay-as-you-go, further reinforcing the flexible and customizable nature of cloud setups. You’re not tied into lengthy payment plans and you’re not forced to pay for a package with elements that you don’t need. Instead you can pay for exactly what you need at that given time and adjust your setup as needed by increasing or decreasing the resources you pay for.
Now let’s get into the techniques for migrating your architecture to the cloud.
Cloud architecture techniques
There are two main techniques when considering cloud architecture for your migration:
- Lift and shift
- Rearchitecting (cloud native)
Note that you can combine these two techniques slightly (lift and shift your setup to the cloud while planning to later restructure it with a cloud-first mindset), but to keep things simple we’ll handle them separately.
Lift and shift
“Lift and shift” is straightforward. You take an application that’s currently on-premises, “lift” it out of where it’s hosted, and “shift” it to be on the cloud instead. At first this can seem like the perfect way to avoid the expenses involved in rearchitecting your apps for the cloud, but there is a major drawback.
While it’s relatively simple to do, lift and shift will mean that your apps can’t take advantage of many of the benefits of being on the cloud, as they’re still inherently designed to be on-premises. For example, cloud apps tend to be more stable (partially because you’re not directly responsible for their uptime) and, when built with the cloud in mind, have lower operating costs over time.
However, there are some situations where lift and shift is still a viable strategy. These include times when rearchitecting on-premises is too expensive or outright impossible, migrating virtual machines, and helping to avoid disaster recovery risks.
In the end, while it can be useful when the other option is too expensive or impractical, lift and shift (without also planning to rearchitect the app once it’s in the cloud) is more useful for legacy apps which aren’t so much the lifeblood of your organization. Most importantly, if something needs to be migrated because it needs to have cloud functionality, lift and shift simply won’t achieve that alone.
Rearchitecting (cloud native)
Rearchitecting is the inverse of lift and shift, in that it requires you to tweak (or entirely rebuild) your app with a cloud-first nature in mind. Yes, that sounds intimidating, but there are plenty of benefits to make it worthwhile.
Rearchitecting is the only way to let your apps benefit from the advantages that the cloud offers. This means increased accessibility (via an internet connection), predictable costs, no maintenance worries (the cloud host runs hardware maintenance for you) and massively increased scalability.
Think about how much you’d need to put in place in order to grow your current on-premises operations. Not only will you need to obtain more hardware to host your apps, but maintenance and security costs will go up to match them.
Meanwhile, a cloud-ready architecture can simply request new resources and be pretty much ready to go. You don’t have to install anything locally so you can deploy changes faster, and (as long as you keep track of your usage) only pay for precisely what you’re using.
When is it worth investing in cloud architecture?
It’s worth investing in cloud architecture more often than it isn’t. The only real reason that it would be better to not plan your architecture for the cloud is when it’s prohibitively expensive or impractical to do so while you’re still on-premises.
Meanwhile, it’s incredibly beneficial to start building cloud architecture when you need more scalability than your data center can offer. Remember that growing in a cloud environment simply means requesting more resources, rather than having to purchase and install entirely new equipment.
It’s also worthwhile when you need to reinvest shortly in a lot of physical resources in your data center. In other words, it can be a great cost-saving measure when your data center bills are up for renewal.
After all, if your apps are on the cloud that’s a chunk less that you need to pay for in physical form.
There’s also security and accessibility that need to be considered.
For example, you probably don’t have governmental-level security protecting your data center. It’s probably locked up at night but even just maintaining the setup with the most recent updates can be a full-time job, let alone keeping it secure.
Wouldn’t it be nice to hand off upgrade and maintenance duties? Well, with cloud architecture and deploying on the cloud, that’s exactly what will happen!
You’ll still need to have some security on your end, but nothing like the direct security of your software’s architecture.
As for accessibility, if you weren’t a SaaS company then it could be argued that on-premises allows for more flexibility. After all, if you have your own server and don’t require a net connection, you can access your programs even if the internet is down in your area (eg, your provider has a blackout).
But you are a SaaS company - being online is practically a necessity.
Always being online means that you naturally always have a connection to the cloud. This means that, even if someone isn’t on-site, everyone can always access your system without interruption. This is especially true when considering that your cloud provider’s lifeblood is based on their security and uptime - it’s in their interests to make sure that if you have an internet connection, you’ll be able to connect to them.
When is it not worth the investment?
There are three main reasons that building cloud architecture would not be worth the investment. These are when you’ve just reinvested in your data center, there are no business demands requiring you to be in the public cloud, and when you can’t afford to hire cloud-native developers to migrate everything.
First, if you’ve recently reinvested in your current data center assets, there’s little point in changing. All that will achieve is wasting the money you’ve just put down. Instead it’s better to wait until you’re closer to a planned capital investment, then look into cloud migration as a long-term cost-saving measure.
You don’t want to waste money you’ve already spent.
Second, there might not be any business demands requiring you to be in the public cloud. This generally means that your company doesn’t fall under Information-as-a-Service (IaaS), Platform-as-a-Service (PaaS) or Software-as-a-Service (SaaS).
If you don’t need to share anything offsite, you don’t need to be on the cloud. You could still benefit (eg, your team working from home), but it’s not necessary.
Finally, you simply might not have the money available to hire the required cloud-native developers to rearchitect and migrate your setup. This is an unavoidable problem, as it’s worth paying someone experienced to do it right rather than risking going halfway and having a broken system as a result.
A compromise, however, would be to get your team to lift and shift your apps to the cloud now, then hiring someone to rearchitect everything later on to take advantage of the setup. It’s not perfect, and you run the risk of introducing unintentional issues, but it’s a good way to get the ball rolling if you know that you’ll have the money to hire cloud developers in the near future.
Pitfalls of cloud architecture to avoid
One of the biggest (and most immediate) pitfalls of shifting to cloud architecture is that your resources will no longer buff up your company’s balance sheet. While data center resources are considered assets (and so contribute to the value of your company), public cloud resources are instead part of your Cost of Goods Sold.
You’re losing the strength of your data center assets and incurring external ongoing costs in the process. Plus any adjustment to your resources later will affect your company’s valuation too. As such you need to have the approval or at least awareness of your financial department before making the change.
There are also the dangers of going from set price to pay-as-you-go. You need to make sure that you keep a close eye on what resources you need compared to what you’re paying for, as the bill can quickly snowball without you realizing if, say, you don’t reduce resources when you’re done with them.
To combat this you need to start managing your cloud finances efficiently. This itself can be a nightmare, but thankfully tools such as the Aimably suite provide a perfect starting point for monitoring cloud spending.
Finally, you should consider spending the extra time and money to get a migration specialist to examine your data center architecture for cloud compatibility.
The danger here is that what works for your data center might not translate to the cloud with the same benefits. For example, the most cost-efficient data center architecture might not make for the most cost-efficient cloud architecture.
Speaking of which, check out these cloud migration interviews to see what others have learned from their own efforts!
Yet, despite its pitfalls, migrating to cloud architecture remains an incredibly strong choice for many companies, and an essential one for any aspiring SaaS company. With a bit of preparation you can avoid any nasty surprises and start reaping the rewards of being on the cloud.
What are you waiting for?
