COVID-19

4 ways to reduce cost and increase liquidity. #1

Many companies are under tremendous financial pressure due to the COVID-19 virus. We sat down to figure out what we can do to help and came up with 4 ways of how we can reduce cost and increase liquidity in the short term for a company. We are posting these 4 ideas in a blog series and in this blog post, we will present the first idea to improve your financials – hardware refresh. Most importantly, we will put numbers on such a refreshment which would cheer up many CFO’s today.

#1 – Hardware refresh in your datacenter

With a depreciation cycle of 36 months, you’re looking at a 33% replacement of servers and storage in your datacenter this year. Now is a good time to challenge the default decision to replace those servers with new ones and consider cloud instead. Here are a few reasons why:

  • You don’t have to make the capital expenditure upfront which will have a positive impact on your cashflow and your balance sheet.
  • You will lower your cost by an average of 30-40%
  • You don’t have to buy capacity to last for 36 months with low utilization the first couple of years.
  • You pay for what you use and you can scale up or down in capacity by pressing a button.
  • You are making the inevitable move to cloud sooner than later

Example – a company with 300 servers, 50TB of storage

In this example, we’re looking at a company with a total of 300 servers and 50 Terabyte of storage running in a datacenter or a co-location. They have a depreciation cycle of 36 months which means that they normally refresh 33% of the estate each year, in this case 99 servers + 16TB of storage.

The graph shows a cashflow comparison between replacing the hardware compared to running the same workload in the cloud. The greatest benefit from a financial perspective becomes obvious in the graph, you don’t have the capital expenditure upfront when using cloud. This company is looking at an upfront cost of 16.1MSEK. Instead of spending 16MSEK in refreshing hardware, it will do more good as free cash and liquidity.

Cashflow comparison of replacing 99 servers and 16TB storage compared to cloud

Another observation is that cloud seems more expensive on a yearly basis and that’s true. However, when considering the upfront costs, the accumulated savings are considerable, see graph below. Beside keeping 16MSEK in the balance sheet, this company would save 4.5MSEK per year or 27MSEK in 6 years by using cloud instead of refreshing the servers.

Accumulated cost comparison between on-premise and cloud

In this example, the customer are paying for the transition project and the cost is included in the business case. Most of the time, AWS offers generous fundings to reduce the so called “migration bubble”, which is the time when you run the workload both on-premise and in cloud during the migration project.

There are of course a lot of ifs and buts in any calculation and the numbers are just interesting if you can identify yourself in them. We have created a template for helping companies calculate a comparison between doing a hardware refresh versus cloud. We can customize most of the data to simulate your specific prerequisites to make it as accurate as possible.

Please contact me or any of my colleagues if you would like to do the exercise for your company, we’re here to help.

Stay tuned for more examples of how we can help you reduce costs and increase liquidity.

AWS

Where do I start with AWS?

So our organization would like to start using or migrate to the AWS Cloud, where do I start? Creating a safe and effective foundation for either a migration or a starter-pack for using the AWS cloud requires substantial cloud expertise and can be a complex process.

We need to design a scalable infrastructure and configure the base environment in which we have to create multiple accounts for accessing multiple resources. Due to the complexity to migrate a large-scale organization, this could lead to several issues such as multiple design architectures, data security, lack of automation etc.

Organizations would attempt to follow the jungle of defined “best practices” before being able to have resources spun up safely. Do we have a consensus on what really are the “best practices”? Is the “best practice” up-to-date as updates are released continuously? This is thoughts that might pop into your head, and it should be taken seriously.

There are however several tools and strategies available to help you with these concerns and challenges. In this blog-post I will introduce you to some of them and what my thoughts are on them.

AWS Landing Zone

Landing Zone is the result of a lot of time and effort spent to define recommended best practices for a multi-account organization and to codify that architecture into a service that is deployable within AWS. It succeeds in creating this baseline infrastructure, but is still fairly complex.

It requires quite a lot of effort to make some of the modular components useful, which could be a downside in terms of an administrative standpoint. Some organizations are used to the AWS cloud and already manage everything with IAC and CloudFormation, this will reduce the amount of time spent on complexity and management of the solution. But it will most likely be troublesome for new AWS customers.

Many organizations have separation of duties between admin and developer teams, when some developers are more familiar with AWS, but a lot of components usually fall under the domain of the admin team which requires them to have this knowledge as well.

Account creation is not as smooth as it could be due to accounts being created in Service Catalog. It could also be troublesome to investigate issues related to the landing zone and does, as previously mentioned, expect a lot of expertise in the area.

AWS Control Tower

AWS Control Tower has a lot of things in common with the AWS Landing Zone solution. It could also be referred to as the “managed AWS Landing Zone”, meaning that this is a service that AWS provides that is equal to AWS Landing Zone, but managed and offered like a service.

So this would then eliminate the time consuming troubleshooting and complexity of the AWS Landing Zone since this is provided as a service? Well, yes in some way. It is much easier to manage and provides you with a lot of great guardrails and best practices, all deployable in an effortless way. There are also integrations to other AWS services which are neat.

So is Control Tower “the shit”? There is unfortunately a but..

While Control Tower offers great features it does lack flexibility and the ability to customize in the way many organizations need.

One of the great features of Control Tower is that you are given guardrails, but you can’t create your own SCPs and have Control Tower govern them. Sure, you can create your own SCPs from AWS Organizations, but you cannot have Control Tower to manage them.

Ability to create new OUs under the root OU (i.e. building a tree-like hierarchy is not currently possible), could be complex if you “drift” the Control Tower configuration.

AWS Deployment Framework (ADF)

This is a framework built by AWS and their enterprise customers, this framework is getting a lot of traction and is popular among AWS ProServe.

ADF certainly provides a lot of great features and does provide something that other solutions don’t. It is like if you have been walking around thinking pizza didn’t have cheese, then ADF would be that cheese which would make your pizza so much more tasty! In other words, ADF might be the piece of the puzzle your organization is lacking.

So what is ADF?

ADF is an open-source flexible framework which helps you to manage and deploy resources in multi-accounts and regions, it is also extensive and allows for staged, parallel, multi-account, cross-region deployments of applications or resources via the structure defined in AWS Organizations.

ADF allows you to do the whole account creation, guardrails and other foundation resources you find necessary deployable using a CI/CD approach. ADF is taking advantage of AWS CI/CD tools to alleviate the heavy lifting and management compared to a traditional CI/CD setup.

Sounds like a lot of work? Well yes, it requires quite some IAC and could be troublesome for users not used to this. It does not give you any guardrails out of the box and is pretty much a platform that you can customize in any way you would like. ADF requires some knowledge to master but has a lot of benefits and is worth pursuing in my opinion, you do not lock yourself in to this solution either as it is mostly CloudFormation doing its work.

As previously mentioned, this is an open source framework developed by AWS and its enterprise customers, but should in my opinion be a service provided by AWS, and maybe it will be some day.

Conclusion

So what is the verdict? Which option is the best one?

I would say that there is no option alone that can fulfil all your requirements. Usually enterprises want to customize their infrastructure foundation to fit their needs and their internal processes etc. Are you fine with a stiff solution providing you with out of the box guardrails and nothing more then I would choose Control Tower.

However if you would like the good stuff that Control Tower offers such as guardrails and the fact that it is a service provided by AWS, plus being able to customize your foundation, I would choose a combination of Control Tower and ADF.

This leaves you with the best practices guardrails provided by AWS through Control Tower and have the ability to customize the foundation to fit your needs using ADF. ADF is also great at managing pipelines at scale and provides transparency through the organization. Pipelines are defined using a file called deployment map which can be modified to fit your needs. AWS Landing Zone is an customizable version of Control Tower but does lack a lot of features that ADF provides.

There is some lacking functionality in AWS CI/CD tools which ADF yields together in a great way. Developers in most organizations have no problem creating new repositories and pushing code to them, but creating CD for their code is not usually something they would like to handle. ADF makes this process much easier. Pipelines are defined in the deployment map, developers can then focus on developing code and keep this up to date in the repository they define.

If you have any questions or just want to get in contact with me or any of my colleagues, I’m reachable on any of the following channels.

Mail: christoffer.pozeus@tiqqe.com
LinkedIn: Christoffer Pozeus