Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Eoin: As cloud consultants, we often talk with clients that are considering moving their projects to AWS, but they have significant fears holding them back. Today, we want to walk you through the most common concerns we hear from customers when it comes to AWS. And we want to disclose some of the answers that we have to reassure our clients. We'll discuss hot topics such as cost, complexity, security, vendor lock-in, and knowledge gaps.
If you are in the cloud consulting business, chances are you are having similar conversations with your clients, or maybe you're trying to convince your boss to move certain projects to AWS and deal with some internal resistance. This episode might give you some ideas on how to reassure your clients or your boss that AWS can provide value. More importantly, we will also share some tips on how to prepare the organization for successful migration, because often these migrations require significant changes to the organization itself. My name is Eoin, and together with Luciano, we are here for another episode of the AWS Bites podcast. fourTheorem fourTheorem is the company that makes AWS Bites possible. If you are looking for a partner to accompany you on your cloud journey, check them out at fourtheorem.com.
Luciano: As usual, Eoin, I think it's a good idea to start by laying down some potential scenarios that we can reference just to understand, like, what are we talking about? What is the context here? And it might be something on the line that you have an application running on-premise and you want to migrate it to the cloud because maybe you need more scalability, because maybe you need new capabilities, or maybe you have some application that is running on some old-school web hosting provider or a virtual private server somewhere.
I'm sure that if you have done any PHP in the past, you probably have been in that situation, and at some point you realize, this is not going to be enough if I want to grow a business. So, again, some reasons why you might want to migrate to the cloud, scalability is probably the first one, but it's not the only one, because another interesting aspect that the cloud gives you is speed of innovation. For instance, you might want to leverage cloud-first services like Lambda or DynamoDB or maybe all the machine learning type of services that you can just use with an API. So that kind of a capability is something that you gain when you start to switch to the cloud, and therefore it might be a good motivation for your organization to consider that switch. So with that being said as a context setting, what is the main concern that we hear from customers?
Eoin: The first one I think is always cost. And the common concern there is, is AWS going to be more expensive than my current setup and then cost predictability? Because previously, while you might have needed a large capital expenditure investment at the start of a project to purchase hardware or some fixed price annual cost, with on-demand compute, you have the issue of predictability. So you have a fixed contract and you want to know, how are you going to pay, how much are you going to pay every year with this new setup in AWS?
And then the other thing is hidden cost. How much is it going to cost me to train staff? Will I need to buy additional support? Will I need third-party services as well to be successful? So this is, I think, the most common concern and probably the most challenging one as well. And it's impossible to say in absolute terms whether moving to AWS will result in a cheaper or more expensive deployment, at least if you're just looking at raw IT cost.
Now, there's a mindset change required here as well. Everything in the cloud is dynamic and consumption-based. You're buying into a more flexible environment, but you also have the trade-off of that flexible pricing for better or worse. So let's try and give some tips for fighting that fear. With this flexibility, resources can be configured up and down. So you pay for exactly what you need and not a penny more.
And you can also back out of decisions and look at ways to reduce cost in a very reactive way as soon as you detect issues with your cost. For certain resources, like auto-scaling groups, you can set auto-scaling upper bounds to avoid unbounded scalability. You can also set billing alarms and notifications so that you can be alerted if your predicted cost is going above your expectations. And we set that up and use it all the time, and it's very useful.
And we very rarely have any kind of significant surprise there. Over time, once your usage patterns stabilize, it will get easier for you to predict cost. You will need to be able to spot opportunities to invest, I suppose, in re-engineering activities to cut costs if needed. And then the other thing is, of course, think in terms of total cost of ownership. And this is easier said than done, I think.
But when you use managed services, the idea of this is that you need less people to look after the infrastructure. So even if your infrastructure bill ends up being higher, you might still be able to save a lot of money somewhere else and even free up people to be able to work on new features and new products that you wouldn't have been able to do if you were just focused on building a lot of infrastructure that AWS are now taking care of. So with this mindset change, you might need to think about restructuring the organization a little bit. You might need more cloud engineers than Sys administrators, but cloud engineers are generally more aligned with your business goals. The idea is that you should be reshaping your teams and your skill sets to be focused more on business-aligned feature delivery than just on keeping infrastructure running. So Luciano, I think that's as much as we can say about cost. What else have we got when it comes to some of the top fears with AWS adoption?
Luciano: Yeah, the next one is one of my favorite ones, which is AWS is too complex. And sometimes it gets a bit funny. Like people will say, I'm not smart enough to use AWS, or I will need a PhD before I'm able to do anything with AWS, which is, of course, an exaggeration, but it's funny to hear that concern in those terms. And more reasonable ways of phrasing that is like, how can I be productive with such a complex environment?
How long is it going to take for me before I'm up and running? Or what if I don't really understand the model and eventually I'm going to end up getting something wrong and that mistake is going to affect the business negatively? And all of these are very reasonable concerns, and it's only fair to admit that AWS is somewhat complex, but that complexity is what gives AWS all the powers and all the nice things that you can do with it.
So I think that the way of addressing this concern is trying to think what is a system that allows me to isolate all of the complexity and all the many things that I see in front of me when I think about AWS, and only focus on the few things that are really important for the organization. And basically you might ask yourself, okay, how do I structure my understanding of AWS so that I can simplify things down?
And one way of doing that is you might think of AWS as an ecosystem of many, many services. There are, I think, more than 200 services at this stage, but in a way you can think about them as different companies, different service providers, and you don't need to buy into all of them. Of course, some of them are more foundational. We can call them this way and you cannot really avoid them. So these are probably the ones that you should focus on first.
Like make sure you really understand them because you will find those pretty much with everything you do in AWS. So I think it's an important first step, but once you have those covered, and I'm talking, for instance, about services like IAM, like for permissions, once you have those covered, you can pretty much roll with them and start to learn more specific services that you need to build specific projects in AWS.
The other thing that you might think about is that these services, you can group them in different areas, like different types of services. Like you might have services for compute, you might have services for machine learning, and you probably don't need to think about all of them. I think only a subset of all the services would be applicable to your business. So that reduces a lot the complexity.
Like you don't need to be worried about all the machine learning services if you're not planning to use this particular set of features. Of course, if new use cases will emerge over time, you can always learn new stuff as you go. So I think that the three steps are try to think about all the AWS services as foundational ones, spend some time and put some effort into learning those, then identify the ones that are really important for you and start to learn them.
Ignore all the other ones pretty much, unless at some point you realize you have a use case for a new service, and then you can start to investigate and learn it over time. Another point is that AWS is quite consistent in terms of experience that you get as a developer or as a cloud engineer. So when you start to be familiar with the concepts that AWS gives you with some of the APIs, I think it gets easier and easier over time because you will spot some of the same patterns across different services and different features.
So just to reiterate some points in terms of the strategy, foundational services first, then you might want to look at best practices and how to bootstrap various accounts. landing zone, for instance, we have a dedicated episode on that. We will provide a link in the show notes. You might want to hire a cloud consulting partner like fourTheorem because that might accelerate the onboarding process and reduce the risk that you might be doing something wrong in the very early stages.
So you are basically set up and ready to go very early on, and there are experts helping you to make sure that all the path is laid down for you rather than you having to figure it out by trial and error and maybe by doing pretty dangerous mistakes that might affect your decision making and thinking that the cloud was a good idea in the first place. And in the company, I think you need to promote a new mindset of this is a learning journey, so everyone needs to start thinking, okay, we need to learn together, we need to have study material, maybe we need to look into certification, whatever we learn, we need to share it and make it available in the company as a team.
And that's something that you can encourage through pairing, training, code reviews and so on, especially if you already have a core team of people that starts to be more skilled AWS professionals, those can be the ones that can help the rest of the organization to basically get better at using AWS and using it correctly. In terms of services adoption, it might be a good idea if you are building a new product and you don't really have technical constraints to look into more serverless services because with those ones, you generally have more managed solutions, which basically means that AWS will take care of a lot of concerns that you don't really have to be worried about and therefore you can focus a lot more on the business value, like implementing the business flows that actually are enabling your business to scale and grow.
And then the usual apply, iterate, keep growing. Another thing that comes up very often in this kind of conversation is building a cloud center of excellence, so trying to build a core team of people, a group of people in your organization that are the cloud experts and they are the go-to to basically try to address any issue or concern that you might have with the cloud. And also that might go around and review other people's code and make sure everyone will get to the point of expertise where they can be very proficient with AWS.
I think the goal is that eventually you want to become a cloud-first company when you start to adopt the cloud. So you have to think about the cloud as a new capability that also requires a little bit of change in your organization, but it will become a very important business tool. So it will enable a lot of things that you are not able to do now, but you will be able to do later and therefore it might give you new business opportunities. So it's a bit of an investment. You have to see it as an investment. You have to understand how much you need to invest and make a plan for that. But eventually you are going to get a return from that investment if you do all of this stuff correctly. Another one that always comes up is vendor lock-in then.
Eoin: So we hear from people, I don't want to use AWS. I don't trust them. What happens if something goes wrong? If the pricing changes, it'll be really hard to migrate away. Or people say, we can use AWS, but we're just going to stick to virtual machines, maybe some Kubernetes so that we can easily move away if needed. Now, it's true that if you're using a lot of AWS services and APIs, you're buying into a very specific technology ecosystem.
And as such, it might be expensive to migrate to something else. But I don't think there's a way of adopting the cloud where you don't have some cost when it comes to migration. And if you're going to try and do it in a vendor neutral approach, or you're just going to say, okay, let's use kind of lowest common denominator infrastructure like virtual machines or Kubernetes, then you're going to put the cost into doing more engineering upfront or into doing something in a cloud agnostic way.
I think no matter what option you take, you're going to lock into something. And if you think about it from the point of view of the AWS shared responsibility model, the idea is you pay them, they'll take care of a certain number of layers of the stack at the bottom, like the core infrastructure, the security of the cloud. And then you just look at the services above that. You understand your business logic, your deployments, your security of your workload.
And if you're not taking advantage of those services, you're essentially taking that responsibility back and you're giving yourself more of a burden. So there's a trade off there, just like with any technology decision, you can get fast time to market, the ability to build highly scalable systems, the ability to swap in and out components of your architecture, to evolve your architecture really quickly, and other benefits in exchange for just buying in and going all in on AWS with their specific tools and APIs.
With abstract approaches where you're saying, okay, let's build our own abstraction to hide AWS underneath and make it more portable, you're just going to spend more time engineering, building these abstractions and distract yourself from just building business requirements. So you might be missing out then on the more innovative capabilities that might be convenient for your business. So in terms of fighting this fear, just accept that any technology choice comes with some degree of vendor lock-in, cloud is no different. And if there are areas of your business that you need to protect, you can always use well-known patterns, like hexagonal architecture, for example, which is quite commonly used in serverless deployment to reduce the coupling between your core business logic and the physical resources you might be working with, like databases, API Gateway, AppSync, or whatever it is. I think we've covered probably the top three ones have we got other concerns and fears from people?
Luciano: Yeah, I think we have at least a bonus one that we want to cover today, and that one is security. And the question we often get or more of a comment sometimes is the cloud is too complex and there are too many security risks. And I'm worried that, of course, that's going to compromise the business because ultimately that's what you want to do. You want to protect your business. So you're trying to figure it out with all these trade-offs that I have to take, is it more of a risk or an opportunity?
And security is always scary. Security is always scary because there is a lot of unknowns and you are more afraid because you don't really have a... You don't always have a way to fight all these unknown unknowns and therefore the worry comes up. So I think in the cloud, it's important to understand that it can be a little bit scarier than the alternatives, in a sense, because if you have, for instance, if you are deploying something on, I don't know, an FTP, right, the old style providers where you just upload files on an FTP and you have a website running, what you are exposed to is very limited.
Maybe they can compromise your website. They can alter the homepage. They can try to steal some user data, all nasty things, but that's limited to basically what you have in that particular account. With AWS, it gets scarier because if you think, what happens if my account is compromised, you may start to think, okay, anyone can start to spin up resources and those resources are tied to my wallet and I will have to pay even for that attack.
So it's not just a damage in terms of reputation, but it can be a pretty significant damage in terms of cost as well. And it might affect the company really negatively. So it's a very reasonable fear, I guess, to have when it comes to the cloud to be worried about security. So with that being said, what can we do? How can we think about this in a more positive way? And I think whether you run an application in the cloud, in your own data center, in your own virtual private server or Austin provider, there is still a security concern anyway.
So the way you build applications, it doesn't change. You still need to implement all sorts of application security best practices to make sure that your application is not vulnerable. So that is not really, that doesn't change, I guess, in the cloud necessarily in a negative way. And actually, there are some new interesting things that you might start to consider that are more in favor of AWS because AWS actually gives you a lot of tools to make your security posture actually a little bit better compared to when you run your own infrastructure or when you run using other kinds of providers.
And one thing is that if you use serverless applications, which is very common when you go to the cloud and you're building something new, it's kind of a default. I think serverless applications are a little bit unique in terms of security because you can be extremely, extremely granular. Like every single Lambda function, for example, can have a policy. So if you're building, for instance, a crude API, you might have different Lambdas to manage different operations and therefore you can say this Lambda can only read data.
This Lambda can only delete data. And you can also be very specific on the kind of data, maybe the table, maybe the record, maybe attach additional conditions to the policy. And that means that if that specific Lambda gets compromised, the surface that is exposed is extremely limited. Now, if you think about a monolith, that's very complicated to achieve at that granular level because generally if a monolith gets compromised, you have the entire surface of the monolith to be compromised.
So this is already an advantage in terms of, because of the cloud, you adopt serverless, you have a lot more control in how granular your security posture can be for different parts of your application. The other thing is that AWS itself is very aware about security and there is an entire suite of services that you can use that are in this kind of security realm. And just to mention some of the capabilities that you can get out of the box just by adopting certain services, you have detection and response.
For instance, by using tools like Amazon Inspector, Security Hub, GuardDuty, so all these tools will help you to monitor your posture over time and spot if there is something wrong and help you to fix it straight away. Then there are more kind of application-based security tools. For instance, if you're building a website, you probably want to use Web Application Firewall or Shield, which are two services that you can just put in front of your application and they will make sure that they stop things like common attacks, like SQL injections or known IP addresses that are known to be bad, I guess, bad actors in the network.
Or with Shield, you can do things like getting some kind of degree of protection against DDoS attacks. Other things that you can do, there are services that allows you to manage sensitive data in a kind of proper way. For instance, you can think about Secret Manager, AppConfig. You have lots of options when it comes to encrypting sensitive data. And if you think that you have to do all this stuff anyway in your own solution without using the cloud, it is a lot of work. And even if you can use open source tools, you need to make sure you install them, configure them correctly, use them correctly. So I think with the cloud, once you start to have a security-first mindset, you have just much more tools that can help you out to make sure you do things correctly.
So just to recap this point, I think security is still hard and something you should build more as a process in everything you do as a business. It's not just like a switch that you say, I am secure, I'm not secure. It's something you always need to think about with everything you build and you always need to observe and you always need to monitor and try to improve. So one thing you will do is try to establish a security baseline, figure out ways to always validate your security posture.
You can use automation, you can use all the tools from AWS, and often reassess and adopt new best practices. Of course, again, the usual advice stands. If you feel that you don't know exactly what you need to do, ask out for help. There are lots of companies that can help you out to make sure that your security posture is correct and that can help you to establish all these best practices so that at some point you can be self-sufficient and confident that you are managing all the AWS security correctly. What else do we have? Is there any other comment that we want to make in terms of AWS spheres? Yeah, I think that was a really good one on security.
Eoin: I think ultimately the capability to do fine-grained security in AWS is like nothing I've ever seen in any other option. So I think it's good to allay those fears. But maybe not so much a fear, but a less common question is, do I really need to move to AWS in the first place, forgetting about the fear factor? And the answer isn't always yes, right? Going to the cloud, it's a big decision. It has substantial consequences for organization.
It's non-trivial. It can have huge benefits, but it shouldn't be taken lightly. So you can always understand the trade-offs and evaluate things carefully. Not all businesses need to be on AWS or on the cloud at all to be able to succeed. If you've got something that's making money, running well, doesn't require a lot of maintenance, speed of innovation, it doesn't necessarily need to be in the cloud.
You don't necessarily need the flexibility or the scalability. So if you decide not to go with AWS, that's completely fine. We're not trying to convince people to go to AWS regardless of the context. You're not necessarily missing out as long as your decision isn't just motivated by fear or fear of the unknown. So I guess maybe just as a recap, I think when you're moving to AWS, it is common to be worried about cost, complexity, vendor locking and security.
There are real concerns. There's ground for them. But most often it's just a strong fear of change and fear of the unknown. So it's important to recognize these fears and the risks that they highlight. But if you're convinced that the migration might be worth it, it's important to approach it as a new step in your evolution. It's not just a technical project. It's quite a radical change in the organization.
It's something that needs to be supported long term. And I think we've both seen in our work that when it is given proper organizational backing and support, then the results can be really, really good. As a long-term investment, it's also important to evaluate the magnitude of the investment and the trade-offs attached to it. Ask yourself, is it really worth it? After all, if your business is running smoothly with your current infrastructure and you don't see many problems in growing the business further, or you don't need to grow that business line further, you might not need to go to AWS at all.
But if you do decide to go, just make sure you understand what are the unknowns, research your best practices, ask for help where needed. I mean, the way we tend to work with our clients is just kind of sitting beside them, co-developing, architecting, building with them, changing things, seeing what happens. And I think that gives people a lot more reassurance that, you know, with AWS, while there are a million different permutations of building any architecture, one of the daunting things can be, okay, which services do I choose? How do I stick them together? So having a little bit of support will help you there because you can get some guidance on the path forward and make decisions quickly. So it's going to be a journey. Just prepare yourself and then start on your path. And don't forget to have some fun. You'll be learning lots of new things and expose yourself to a lot of new opportunities. And with that, as usual, let us know if you have any different perspectives or experience. We value your opinions and we can certainly learn something from all of you out there as well. So do let us know. That's all. Thank you for staying with us. And we'll see you in the next one.