Migrating to AWS has a number of benefits over running workloads on-premise on top of the often promised cost reduction. These include improved security and operational resilience, data-centre consolidation and improved staff productivity. Obviously, cost is a huge factor in any IT spend and understanding transitioning from CapEx to OpEx and a more transactional cost model can be complex to navigate. This is not the disaster it may seem and is almost inevitable without using Lift and Shift as a stepping-stone to leveraging the real power of a cloud migration.
We look at a Lift and Shift migration as a way of solving Infrastructure challenges and it's certainly a great initial solution for many use cases. There are further steps an organisation can take to get to an optimised Lift and Shift as shown in the diagram above. Making sure servers are auto-scaling to serve only the current demand, optimising storage and improving purchasing elasticity are all great ways to bring the cost below that of an on-premise solution. But there are further cost savings to be realised through Application Modernisation, which is where D55 specialise.
A lot of application development over the last 15 years has trodden the familiar path of a three-tier architecture with Database, Business Logic and UI. It's what Microsoft told us to do, and for a while it was great! We can migrate this with containerisation and the Relational Database Service, and there will be some efficiencies like load balancing and auto-scaling that we can certainly benefit from. But, we're still paying for that database service for multiple environments whether we use it or not and we can't independently scale different parts of our application which would bring further cost reduction.
This type of application is known as a database-integrated monolith and eventually, we will get to a point where it can only be scaled vertically. We can derive services from the application code but if they all talk to the same database they can never be true microservices that would benefit from independent scaling and release.
A modern, cloud-native application would split the above workload into a set of AWS Lambdas, API Gateway and DynamoDB. These are all Serverless services that are billed only when used. If we provision a UAT environment but have long periods where it is not actively used, there will be no cost whatsoever. The same goes for a developer environment (or many developer environments!).Write less code!
Serverless applications have built-in service integrations, so you can focus on building your application instead of configuring it.
The cost benefits of cloud-native applications are much further reaching than simply cheaper transactional costs to run the applications themselves. Cloud-native application development lends itself extremely well to achieve a massive boost in developer productivity. Great DevOps is a must because we want to be able to stand up and tear down consistent, complex environments at the touch of a button. So we build pipelines in code, that deploy infrastructure as code and can have an entire environment per developer or even per feature, without paying for it unless we use it. We can also derive microservices with separate datastores to enable independent release and break up the dependencies hidden in our monolithic database.
Application modernisation is also a great time to add in really good automated test coverage, tracing and observability so that we have confidence that we can release our applications at any time without risk. This brings huge benefits in terms of getting to market quickly as does only writing the code we need to. AWS is made up of over 200 services that we can consume. Typically by writing cloud-native applications we can write and maintain far less 'plumbing' and 'helper' code because AWS have already written it for us. So less code to write, test and maintain delivers further cost savings and increased reliability over time.
Modernising an application is a great start but there are further benefits in migrating all of our applications. Introducing a technology like Amazon EventBridge means that we can create events from our applications and then react to those events with AWS services or other custom applications. It also means we can store our events for replay later as we develop further products. We can also use all of our data and events as a source for a Data Lake using AWS Lake Formation and then benefit from advanced analytics and Machine Learning technology available as services from AWS.
At D55, we have a toolkit of patterns and practises to bring all of these ideas together and we would love to talk to you about them. If there are any problems in your solutions that we can help with, get in touch today!
Insights & experience