A look at AWS antipatterns: What not to do in the cloud

If you lift and shift a monolithic application or carry organizational silos to the cloud, then you'll probably have the same problems there that you had on premises. The cloud won't magically make your operation more efficient, so you'll need the right design patterns.

In this Q&A, Clive Harber, co-author of Implementing Cloud Design Patterns for AWS -- Second Edition and CTO of Distorted Thinking, a software consultancy, explains how to avoid common AWS antipatterns and counterproductive cloud processes -- and how business-driven risk aversion is behind it all.

In particular, the book's ninth chapter, "Antipatterns -- Avoiding Counterproductive Solutions," tackles issues such as devotion to a monolithic structure or singular cloud vendor. You can read the complete antipatterns chapter here.

Editor's note: The following transcript has been edited for clarity and length.

You write in this AWS antipatterns section that culture is the largest inhibiting factor when it comes to moving to the cloud . What can organizations do to align their culture for the cloud before migration?

Clive Harber: A lot of, we'll call them "traditional companies," tend to build their organizations in such a way to avoid risk, whether it's in an application, in infrastructure or in their deployment process. So, the whole idea of moving to a cloud-based system is to help mitigate some of that, but a lot of organizations tend to bring forward risk aversion strategies, such as setting the control boards and various elements of technical debt.

Click on this image to
purchase the complete guide.

Before migrating to a cloud offering, it's a good practice to understand your application -- what your application process needs -- and whittle away some of the risk aversion and risk mitigation processes that have built up over the years.

You should take out these sources of technical debt, because you're providing a reproducible, automated process to deploy your application into which you can start to remove some of the brakes. You need to take away the control boards and all the unreproducible manual operations that take place within the traditional deployment.

You should move your application or infrastructure slowly, step-by-step, so you understand what it is you're asking the cloud platform to do, which is different than what you would ask a traditional hosting or traditional application deployment environment to do.

One of the antipatterns featured in this chapter is about vendor lock-in. How can companies balance the benefits they get from buying into AWS or another cloud platform, while also maintaining flexibility and avoiding lock-in?

Harber: By the very nature of what AWS offers, it can be seen as quite a major lock-in to a single vendor. Same as if you were to migrate your application to Microsoft Azure or Google Cloud Platform. But technologies like Terraform, which we also cover in the book to a basic degree, allow you to abstract away those sorts of lock-ins. You can target different parts of your deployment to different platforms, should you so desire. So, if you wanted to experiment with a different cloud provider, you could use the same deployment process but move the targeted part of the application to a different provider using the same process. You could mitigate your losses that way.

The book frequently explores how Netflix uses Amazon. Is Netflix the prime model for how enterprises should approach cloud computing?

A lot of the antipatterns come up when traditional, non-cloud companies come online.

Harber: Netflix can be seen as a torchbearer, if you like. A lot of the practices that have come out of Netflix, like chaos engineering, you can see as a path forward. But there are very few organizations in the world, practically, that will reach the scale that Netflix is on Amazon. But you can plan your trajectory of deployments to Amazon based on the learnings that Netflix has passed on through the years. But there comes a point where you need to realize you're not going to scale beyond a certain point. So, there's no point modeling your entire process against Netflix, because you're not going to get there, in practical terms.

So, take what Netflix has done, understand how they've done it and then apply it to situations based on your own corporate model and your own philosophies.

Were there any antipatterns that didn't make the book or ones that you've come across since its publication?

Harber: The book covers what will come up in general, such as passing on technical debt so you're continuously firefighting. There are corporations that will do that and will accept that risk and cost. Another is not maintaining your infrastructure as well as you should through version control or some sort of other management.

Again, a lot of the antipatterns come up when traditional, non-cloud companies come online, trying to impose what they think is the solution for them without understanding how the cloud works and how to move away from their server-based solution into a cloud platform. A lot of the antipatterns are based on lack of understanding, lack of knowledge and lack of willingness to take a risk.

The marketing side and sales side feel as though they have a tighter grip on technology than they really do. They tend to drive this culture of risk aversion. They see the cloud platforms as there to save money, without changing internal processes and understanding how the organization and the technology needs to change in order to make the best use of the facilities and the products available on cloud platforms.

So, it's a lack of understanding, not putting the money and resources upfront to break monolithic applications down into services, to create microservices, to understand how microservices need to work together. It's these sorts of things that the antipattern section is there to combat.

When you're writing a section like that, you can feel as though you're preaching to the converted. But it's more of a case of trying to give the logical people in organizations the information and the data to go into their company and say, 'This is better. Do it this way. Yes, it'll cost us a little bit more upfront, but then these are the savings, these are the benefits and how to combat this risk averse culture in the business and enterprise.'