AWS is Awesome, But Keep Your Independence Too

It’s the start of a new year and a great time to reflect on where the atmail journey has taken us and where we are headed. atmail, at its core, is a software development company that solves the email headache for telcos, ISPs and hosting service providers. In short, we offer stable, scalable, secure and cost-effective email solutions for large user bases.

Over the course of 2018 and 2019, we evolved from a company that simply writes software to one that both writes and hosts software, and now we stand out in our market as a true cloud provider of reliable email services. Through this transition, we have mentally and emotionally become an AWS shop: we think AWS first.

However, our acclamation comes with a degree of reservation. Having recently returned from the annual AWS re:Invent, we think it’s important to speak up about the need to maintain a level of independence from AWS too. Here’s why…

 

The reasons for AWS

As a company, we have committed to AWS for various reasons. Firstly, AWS does a lot of the heavy lifting for us outside of our core technical competencies. AWS gives us high availability database layers, network load balancers, autoscaling, service monitoring, and so on. In the past, we had to roll all of this on our own. In our OpenStack-based solutions, we had to: build and manage the MySQL Galera clusters; deploy, configure and maintain the HAProxys; and so on. With AWS, it’s just a simple click of the button and boom, there’s your HA Aurora DB. Understandably, there is a lot to love about that.

Secondly, one of the reasons we adopted AWS has been its credibility. In the past, when we walked into a room to talk about our cloud solutions, we would need to spend 30 minutes explaining what Openstack is and who our selected provider in that part of the world was. Today, that conversation takes 30 seconds. Question: “Who do you host your cloud on?”. Answer: “AWS.” Next question.

But thirdly, probably the biggest gain we’ve had from adopting the AWS ecosystem, has been the commercial pathways. Unlike OpenStack, AWS is a full-blown commercial environment as much as it is a set of tech tools. AWS is more than just an extension of Amazon’s online marketplace. AWS have pathways to your current and future customers. They are better aligned to businesses such as ours because they invest in sales teams and are compensated to help you to help your customers.

 

The reasons to keep your independence from AWS

Whilst I wax lyrically about the opportunities that AWS provides for software vendors to move into and embrace the cloud, I do believe that we must also be very careful. AWS are moving “up the stack” – they are no longer just IaaS providers, they are now legitimate PaaS and SaaS providers, and it is very easy to to just click that button and replace one of your competitive advantages or key competencies and accidentally place that into the hands of AWS.

Whilst at AWS re:Invent this December, I was amazed at the constant release of new technologies and offerings. Sure, there were the usual new shiny EC2 instances, but it was the non-infrastructure solutions that had me concerned, as the CEO of a global software company.

For example, AWS API Gateway. With this service, you can simply define some web end points and link them to some AWS Lambda functions, and you have a fully scalable, highly available, web service. Great! But what you might have missed is that you are now locked into the AWS environment. That code is not transportable. You can’t simply lift and shift deploy that into Google Cloud, Microsoft’s Azure or your own Linux server. You are now running proprietary. The same can be said for many other services offered by AWS – and this is the big trap for software vendors as they navigate the cloud journey.

It is quite funny to me, reflecting on the Werner Vogels (CTO of Amazon AWS) keynote at AWS. He asserted that companies are sick of being locked into proprietary solutions such as Oracle, SAP and Microsoft database solutions, and they are now embracing AWS Aurora as an “open technology”.  However, as these same customers venture further into the AWS technologies, they may find, quite accidentally, they are fully deployed on an AWS proprietary solution – exactly the route that Vogels championed against. The lesson we came back with? Be careful what you deploy and architect with, otherwise before you know it, you might inadvertently find yourself locked into the new proprietary provider on the block: AWS.

 

Guiding principles

atmail is a small company, and we have learned over the last 20 years that we need to be flexible. This means that, if we have a customer who wants to deploy inside of their national borders, we need to be able to do that – with AWS or not – so we can’t be locked down to a single cloud provider. We need to be able to deploy on GCP, Azure, OpenStack, AWS, VMWare, KVM, and so forth, as our customer’s situation and needs dictate.

With this in mind, here is a list of guiding principles that we commit to architecting to, in order to ensure platform neutrality and avoid any proprietary lock-in:

1. Our code must be able to run on a local Linux install as easily as it is deployable to any cloud platform.
2. When we call an API, it must be readily available on any other cloud provider. (e.g. MySQL DB calls, be it Aurora, MySQL or MariaDB). Note: Watch out for when AWS introduce a new special feature into Aurora that is only available in Aurora by using their one and only “special call”. Avoid it, run!
3. Only use basic, low-level, cloud services that are available on at least two other cloud providers (e.g. Network load balancers: yes. A platform-dependant, key-value store that is not easily replaced: no.)
4. Abstract all services from their implementation (Note: We love Golang’s interfaces!)
5. There must be a legitimate open source alternative to the cloud offering.
6. Be very careful and clear on our own key competencies (ie. only offload non-core capabilities). We are email experts, anything email is on us – the transport, the hygiene, the access to and the storing of email is ours to own – so we will not offload.

 

Final word

My final word of warning to other software vendors is:

Do not get sucked into the vortex of your cloud platform provider. AWS (or your provider of choice) might be awesome but remain independent.

Remember when we were called ISV’s (ie. Independent Software Vendors)?

Enjoy the perks of the new technology providers, but above all else, be conscious of your outsourcing decisions and if you want to build your company for the long term, remain independent!