Make the Most of Your Migration To AWS Cloud
Usually, big companies' innovation teams are the first to use AWS because it's easier to experiment and much easier to launch new things.
Join the DZone community and get the full member experience.Join For Free
Businesses run workloads on the Cloud when planning new projects, most likely to do with innovation or doing something new. Typical first workloads that we see are web applications, often because of Amazon Web Services (AWS)'s scalability, which is impossible to have the same scalability on-prem. Usually, big companies' innovation teams are the first to use AWS because it's easier to experiment and much easier to launch new things.
In the last two or three years, Artificial Intelligence machine learning has risen as a popular workload. Very few companies today do AI/ML at scale on their environment. It's so much easier to do it on a platform like AWS because of all the data storage services you have and the pre-configured services at your disposal that are much easier to use and leverage than setting up your own tools and applications.
Migration is undertaken when businesses consider migrating existing workloads that today run on-prem. And when you get on to the Cloud, you should make sure you know well about where to start, how to approach it, and which pitfalls to avoid.
Migration, by and large, is a great idea. You will typically have to defend that from a benefit and cost point of view. What are the future benefits? And how does it stand up to my cost in my current situation?
Why Migrate To the Cloud?
A lot of companies migrate to the Cloud for business agility. They want to reduce time to market, build, deploy, and run new things in their environment. But such a move will take much more time and many more processes and involvement of people. And with the average IT shop having a backlog of any way of things they need to do, it isn't easy to do that in-house.
If you do something new, you run it in-house, and you are successful if it's successful. It needs to scale up quickly. That, again, is very hard to do in-house. And therefore, we see a lot of companies saying, 'Well, I need business agility. As an IT shop, I need to support my business better and support my business better. Productivity means we need to get new functionality faster to market or deploy that functionality more quickly in other markets.' That is the primary reason to go to the Cloud.
In the Cloud, you can find innovation departments to reduce cost, the increased pace of experimentation, the ability to spin something up, try it out, test it out. And bring it down. If it wasn't successful, think about it, go through your lessons learned, and try something else again. It can be done at a much lower cost than you could ever do in-house.
Why Migrate To AWS?
AWS runs a perfect platform and gives you lots of abilities to run active across different availability zones. It is a resiliency level that's, again, very hard to match and very costly to match in an on-prem situation.
Another one is regulatory compliance needs to inherit a lot of regulatory compliance. And there's a lot of certifications at the stations that come with the platform. You still need to make sure your workloads and how you set them up meets those compliance requirements, but AWS sets it up in such a way that they manage their part. Remember, the shared responsibility model means that a lot of things you inherit, you don't have to do it yourself.
A lot of customers perceive that the Cloud is more stable. They have fewer outages, partially because the cloud platform is quite good and relatively stable. Secondly, when running successfully on the Cloud, a lot of people start scripting. So, if a workload is deployed, it's going to be completely automated. Once automated, if it needs to be started rebooted, you can automate that. So it's easier to make a self-healing infrastructure. And you can do that on-prem as well. But the fact of the matter is that it happens more and more on the Cloud. Looking at workforce productivity and automation, you invest once in the automation, but you have savings in manual processes.
Again, planned and unplanned outages are at a reduced cost. It's much easier to bring something down, bring it back, plan outages, etc. Or if it's an unplanned outage, to restore services.
What we also see is increased developer productivity. Once developers start using all the higher-level services like simple notification services and spin up a new RDS database, a developer no longer has to go to a database group to ask them how to do that. They had to plan it. They had to have the capacity and time available.
And then we have the last two—cost avoidance at your exchange, CAPEX or OPEX. You don't need to have all the hardware refresh programs eliminate the elimination of the mandatory maintenance. And the fact that the unit price is minimal, you can expand. You don't need to have a reserve capacity because AWS has that for you and only pays for what you use. So that's saving, but also, you can grow very granular at a minimal level and spin up a small extra service for a few additional gigabytes of memory. Whereas a couple of years ago, you would have to buy a whole new box or a whole new piece of kit.
You have the option to do lots of things, but you don't pay for it until you start doing it. And I know we don't like to go through these AWS invoices that go page after page after page; which account is used? What service? I've seen monthly bills that went over 100 pages.
But a lot of business cases don't look at any of the other benefits. And the funny thing is that most companies tell us that those other businesses, agility, resilience, and work for productivity, aren't why they go to Cloud. But in the business case, they only look at hardware software, data center cost, and then miss a lot. A lot of that means that the value you expect to have in the Cloud is not expressed in a business case.
Opinions expressed by DZone contributors are their own.