This article was jointly written by Container Solutions engineer Anne Currie and Michelle Gienow.
Once upon a time, the world’s most advanced technologies were attainable only by large enterprises. Companies who could maintain in-house IT teams dedicated to the development, care and feeding of powerful but still-immature innovations like containers and microservices.
Cloud computing has changed that forever.
These days, cutting edge technologies are available to anyone with an internet connection. Anybody with an idea can go to Amazon, Microsoft or Google, sign up for a fully-provisioned platform as a service and be up and running in minutes. Competition is fierce, and prices are falling while features are expanding exponentially.
So the cloud now seems to be disrupting every industry it touches, and companies are understandably eager to migrate operations.
But not so fast! Despite the massive potential it offers, the cloud environment is not a magical panacea to fix all operational challenges. There are in fact two quite considerable problems when it comes to cloud computing.
Problem #1: The cloud is not for saving money
The benefits of operating in a cloud environment are very real. But if you think of the cloud as a way to save on expenses, you will be disappointed. Moving to the cloud is bound to cost more money because you are paying your provider for the development of all these new and powerful cloud services -- whether or not you are actually using them.
When an enterprise looks at cloud migration, attention is first directed to moving infrastructure off-premises.
The immediate benefits are real: you don’t need to manage those servers anymore, freeing staff to focus on developing your actual product or service. There’s the additional risk reduction benefit, also very real, in not risking massive capital investment in any one technology that may turn out to be the wrong choice. On the cloud, it’s vastly easier to pivot.
While a simple “lift and shift” of existing operations and culture does harvest both of these initial advantages, it does cost more money than running on-premises infrastructure and services. It also utterly fails to capitalize on the true benefits of the cloud. Meanwhile, you are paying for the development of all these cloud services that you’re not using, and your ops team had to learn a whole load of new skills to get you there -- but, ultimately, you’re not really getting any great new benefit.
The solution to problem number one is simple, but not easy: you need to make significant changes in how you do business, in order to optimize doing business on the cloud.
Problem #2: The cloud is expensive, so we are going to save money by building things ourselves!
Imagine you understood all that, and are willing to transform your architecture to reap all the potential advantages of moving to the cloud. You intend to go faster, thanks to the cloud, and microservices are what helps you move faster, so now you’re going to start building yourself some microservices!
The realization that the cloud is more expensive might lead to understandable but misguided attempts to save money by building some of the pieces yourself.
For example, rather than using a distributed database as a service like Aurora, which is pricey, you think you might just build it yourself in your brand new virtual data centre. But building these to high resiliency and redundancy is very, very hard. You have to hire experts, and it takes loads of their time. Even if you already have those experts on staff, is that really how you want them to spend their time?
The heart of problem number two is, having made it to the cloud, people don’t always understand the value of the services now at their disposal.
The cloud, in essence, provides a host of automated specialists. Taking advantage of this is key to truly accelerating development speed. This is what Cloud Native pioneers like The Financial Times, ASOS, and Starling Bank are all doing.
Increasingly, it’s what your competitors are doing.
A common reason why people don’t use these special services is that they fear lock in. They want to keep all options open. For example, if you go with Amazon Web Services, how to know at first if you really want to commit to their Relational Database Services? What if there is some better, or (admit it, the thought still lingers) cheaper way?
At these times, the thinking usually goes, ‘We will have to use these systems, someday, so why not build up front?’ - a totally understandable instinct.
However, when first migrating to the cloud, you are far better off using the tools on offer. Saying, instead, ‘What if we don’t build it right now, start out with this off-the-shelf system and see what happens?’ It may very well happen that you never have to build your own because the platform providers are doing their level best to anticipate and fulfill those needs before you even reach the cloud.
We have seen this first hand with ITV, the British entertainment network that moved from legacy tech - some as old as 1950s vintage! -- to Cloud Native over several years. It was earlier days for cloud technologies, and ITV had a serious fear of lock in. They only wanted to use cloud services they felt they could reproduce in-house if necessary, in case of some unforeseeable failure.
Quite quickly, though, ITV came to see the vast advantages in trusting the platform and began taking increasing advantage of all the services on offer, shifting their homebrewed solutions onto the provider’s plate. And have been quite happy with the results ever since.
We aren’t saying to just blithely use whatever AWS or Azure or EWS pre-packages for you. Before choosing, say, AWS Lambda for your serverless operations, you do need to make yourself happy that there is an equivalent open source system, that would have similar APIs or tooling, that would make shifting easier if the need ever arose. We’re using Lambda as an example here because it is probably the highest lock in service, but in every case please have a think on things first.
That said, there really is no need to fear. Running on AWS is the new buying IBM - no one ever got fired for running on AWS (or Google, or Microsoft). You can rely on the fact that this is not a single point failure risk for your business.
So the answer to problem number two is, trust the platform. We’ve come this far, and there are now quite powerful, specialised, and beautifully integrated tools at our fingertips. It only makes sense to use them.
But which tools, and how to best use them? That is what we shall be looking at next time: how to take advantage of the cloud once you’ve moved there, using the Cloud Native approach.
Feature photo by Cassie Boca on Unsplash
Want to learn more about Cloud Native? Download our free eBook below.
Previous article
