Trying to figure out if Amazon Web Services (AWS) is right for you? Use the “quadrant of doom” to determine your answer. When designing a Cloud architecture, there are factors to consider. Any system you design exists for one reason - support a business. Think about services and their features to make sure they’re right for your implementation.
Today, we’re talking to Ernesto Marquez, owner and project director at Concurrency Labs. He helps startups launch and grow their applications on AWS. Ernesto especially enjoys building serverless architectures, automating everything, and helping customers cut their AWS costs.
Some of the highlights of the show include:
Amazon’s level of discipline, process, and willingness to recognize issues and fix them changed the way Ernesto sees how a system should be operated
Specialize on a specific service within AWS, such as S3 and EC2, because there are principles that need to be applied when designing an architecture
Sales and Delivery Cycle: Ernesto has a conversation with a client to discuss their different needs
Vendor Lock-in: Customers concerned about moving application to Cloud provider and how difficult it will be to move code and design variables elsewhere
For every service you include in your architecture, evaluate the service within the context of a particular business case
Identify failure scenarios, what can go wrong, and if something goes wrong, how it’s going to be remediated
CloudWatching detects events that are going to happen, and you can trigger responses for those events
Partnering with Amazon: Companies are pushing a multi-Cloud narrative; you gain visibility and credibility, but it’s not essential to be successful
Can you compete against Amazon? Depends on which area you choose
Expand product selection to grow, focus on user experience, and improve performance to compete against Amazon
MiserBot: Don’t freak out about your bill because Ernesto created a Slack chatbot to monitor your AWS costs
Full Episode Transcript:
Corey: This week’s episode of Screaming In The Cloud is generously sponsored by DigitalOcean. I’m going to argue that every cloud platform out there biases for different things. Some bias for having every feature you could possibly want offered as an added service at varying degrees of maturity. Others bias for, “Hey, we heard there’s some money to be made in the cloud space. Can you give us some of it?”
DigitalOcean biases for neither. To me, they optimize for simplicity. I polled some friends of mine who are avid DigitalOcean supporters about why they’re using it for various things, and they all said more or less the same thing. Other offerings have a bunch of shenanigans, root access, and IP addresses. DigitalOcean makes it all simple, “In 60 seconds, you have root access to a Linux box with an IP,” that’s a direct quote albeit with profanity about other providers taken out.
DigitalOcean also offers fixed-price offerings. You always know what you’re going to wind up paying this month, so you don’t wind up having a minor heart issue when the bill comes in. Their services are also understandable, without spending three months going to cloud school. You don’t have to worry about going very deep to understand what you’re doing. Its click a button or making API call, and you receive a cloud resource. They also include very understandable monitoring and alerting.
Lastly, they’re not exactly what I would call small-time. Over 150,000 businesses are using them today. Go ahead and give them a try. Visit do.co/screaming and they’ll give you a free $100 credit to try that. That’s do.co/screaming. Thanks again to DigitalOcean for their support to Screaming In The Cloud.
Corey: Hello and welcome to Screaming in the Cloud, I'm Corey Quinn. I'm joined this week by Ernesto Marquez who's the owner and project director at Concurrency Labs where he generally tends to spend his time helping startups launch and then grow their applications on AWS. Lately, he's been emphasizing serverless architectures where he automates a whole bunch of things and helps customers with some aspects of the same problem I deal with, the horrifying AWS bill. But before you did all of that Ernesto, you were a manager both at Accenture and AWS. First, welcome to the show.
Ernesto: Hi Corey. Thanks a lot for inviting me. It's my pleasure to be here. Thanks for the intro as well. Yes, I used to work for AWS but before I joined AWS I used to work for global consulting firm Accenture ask for around 10 years mostly in Vancouver Canada. I used to work mainly with large telecommunications carriers in Canada. Basically delivering software in a lot of areas related to the telecommunications industry like from customer care, to building, to ordering, provisioning.
A lot of systems that are part of pretty much any national telecommunications carrier. The cool part about that is something that I had exposure to basically systems that impact millions of people. telecommunication companies of course, they do have millions of subscribers and they run a lot of critical systems that cannot go down and that was something that I enjoyed a lot like being part of delivering a software in that type of environment. Eventually, I was responsible for leading the performance test practice with one of our clients.
That basically means running all these validations and inducing load on systems before any type of feature goes live right to make sure that basically, things don't crash once they go live in production. So I was responsible for that and that was basically my last role before I decided to join or to apply for AWS in Vancouver that was back in 2013. Amazon expanded into Canada, into Vancouver specifically so they did open a development office in Vancouver for many areas of Amazon for the ecommerce side and also for AWS.
Corey: So you were joining Amazon in Vancouver, and then the burning question I'm sure most of our listeners are going to have I know that I do, what product can we blame you for?
Ernesto: I was part of the simple workflow at teams in Vancouver. At that time, there was a development team in Seattle and we started to build a development team in Canada as well. Yes, that was mainly the simple workflow product and I was also involved with this feature called CloudWorks Actions which you might be familiar with it. It's basically a way to react to specific alarms in CloudWorks. You configure let's say an EC2 Instance or an alarm in an EC2 Instance such that when the CPU utilization goes beyond 60% or whatever percentage, you can do things in response to that alarm.
There are things like stopping an instance, or rebooting the instance, or terminating it or things like that. I was responsible for features related to the CloudWorks Actions as well. As a software development manager, you're also responsible for operating services. So you're part of the whole escalation chain whenever something goes wrong, and I was part of that. I was involved in many operational resolutions as part of the simple workflow team and also as part of CloudWorks Actions. That was probably one of the areas where I learned the most when it comes to how Amazon does things. Like how Amazon operates their services, how they keep their lights on.
Corey: Fairly well generally speaking.
Ernesto: Absolutely, yes. The level of discipline and process and basically the willingness to recognize when something is not right, and just doing the right thing to fix any type of issues. It is really outstanding, and that's something that really changed the way I see how a system should be operated. A lot of those principles are transferable to like a small company that's running a small system or to a large enterprise that is running a multimillion-dollar type of application. That was something that I would say I enjoyed to learn that. It's also very challenging to be part of that type of environment that is very demanding in terms of the high standards when it comes to maintaining operational excellence.
Corey: One thing I find interesting is that after you left AWS, you became an independent consultant. I do the same thing. But whereas I focused on instead of being brought in AWS across a very specific client niche as you have, I focused on solving a very specific problem that then tended to map to AWS customers of all sizes. There's nothing right or wrong with either approach, I'm just curious about how you wind up viewing your work in that context.
Ernesto: I see. Yes, you're right. There are two different approaches. I think in general, the important thing is to specialize on something very specific within the AWS…
Corey: There's over 120 services, if someone claims they're an expert in and all of AWS, they're lying. No one has it all.
Ernesto: No, absolutely not. I mean there are a number of principles that you need to apply when you design an architecture. There are number of what I call foundational services that you must know. Those are the must-haves like the S3 and EC2, all that type of stuff. Yes, there is a foundation. But then, somebody who says that they know every single service, that's just not possible.
So the important thing, in my opinion, is to really focus on one area. Either a technology within AWS at or in my particular case, I focus on a particular segment, on a particular market. In this case, I work with typically small to medium start-ups. The way I segment my market is basically those companies that spend between $5,000 and $25,000 a month in AWS. So that covers a certain rate, a very specific range of companies. You're right at this number and at this market just basically by talking to people.
When I was starting my own practice, I just basically spent a lot of time reaching out to people everywhere, people I knew, people I didn’t know, and many of them were generous enough to give me half an hour of their time and tell me about their specific problems. I arrived at that conclusion for my particular goals and my particular case, I decided that that was a market that I wanted to tackle.
So far, that's something that I have enjoyed a lot. I do enjoy working with this type of companies. Something I really like about it is that I get to talk to the decision makers right away. Typically within this segment, I end up talking to the CEO, technical founder type of person, or the CTO type of person. We have a conversation, we talk about the different needs. I come back with a proposal and we make a decision or they make a decision right away.
Basically, the sale cycle is very efficient in that case, and that's something that I enjoy. Not only that, normally the sales cycle but the delivery cycle as well. I get to talk to decision makers if something needs to be done, the decision gets made fast. That's something that I enjoy, I get to make an impact on businesses. I impact a significant number of people and also that impact substantially the business owners and their customers. I do enjoy working in that type of environment.
Corey: It definitely seems like it has a certain panache to it. What I found interesting what first brought you to my notice, what I found interesting and first brought you to my attention is you wound up having a fascinating article, I'll throw a link to it in the show notes, on effectively how to wind up figuring out whether an AWS service is right for you. You had something in there that I guess I'm going to call the quadrant of doom where you wind up discussing a variety of services in a multi-club context versus basically on an axis of how easy it is to migrate off of them. I'm oversimplifying to a point, but that effectively is something I hadn't really seen before as we have these ongoing debates about, "Should I prepare to go multi-cloud." my default response to that is generally, "No, go all in and instead, if you need to migrate later, deal with it then." you take a more nuanced view. Can you talk about that a little bit?
Ernesto: Yes, absolutely. When you're designing a cloud architecture, there are a number of factors that you have to consider. In many cases, I'm a technical guy. It's kind of in my nature to try to jump and start to think about things in technical terms and particularly AWS services and things like that but that's something that has to be decided in a careful way before you get there. You really have to understand before you do any of that. You really have to understand the business that is behind those systems.
Any system that you design exist for one reason and one reason only which is, to support a business. That's kind of like the context that I try to bring into the whole process. At some point, you're going to think about the services that you're going to use and then the important thing is you have to think about all the different factors, all the different features, all the different things that are associated to that particular service and make sure that they are right for that particular implementation. One of the things and you're referring to this item the quadrants of doom.
Corey: Well anything else? That might be I think magic axis of doom or something because I'm sure the word magic, quadrant and probably doom are still trademarks of Gartner.
Ernesto: Yes, okay. It's essentially let's call it a little X Y axis chart, let's take a look at something that is very important when it comes to using a particular service which is the vendor lock-in and a lot of AWS customers are concerned about vendor lock-in and justifiably so, you're moving your application to this cloud provider and you want to know how difficult it will be in the future to move somewhere else if for whatever reason you need to move.
That's an important thing to consider and yes, a lot of a lot of customers are concerned about that. They see that there are a lot of cool features, a lot of cool products in AWS that result in a heavy type of vendor lock-in. that's why I've been thinking about that. from an application owner point of view, there are probably more variables but there are two that I find that come up regularly which is, my code and design.
How much changes do I need to make in my application if I want to migrate out of AWS? So those are two factors and they are services. They live in different parts of this spectrum when it comes to complexity. So for example, there are services where it's going to be relatively easy to migrate out of AWS. There's basically nothing that you need to change in your code, or nothing you need to change in your design. But there are services where you potentially need to rewrite the whole application if you want to move out of AWS.
It's important to understand that. I mean there are some examples, I can mention some examples of services where it's relatively easy to move in and out. For example RDS. RDS, that one 's easy to move out of AWS. You're using my sequel, or sequel server or whatever database engine that is available. That's not a big deal for your application. You don't need to change a lot of code, you just basically need to change some config files and you need to migrate your data out of AWS.
That would be a considerable task but from your code perspective, you don't need to change much. There are other services for example Lambda which I mean, I love Lambda, I use it all the time. It is one of my favorite services but that's a service that if at some point you want to migrate out of AWS, you're going to have to redesign a lot of stuff, and you're going to have to rewrite a lot of code most likely. You basically need to be aware of what it would mean in the future if you want to move out of AWS potentially.
Corey: Absolutely. That's part of the challenge I think, that people wind up missing at times is there is a question of what is the eventuality you're aiming at here. Is it if you want to be able to move strategically down the road, if a provider does something you don't like. Well spoiler, everyone's going to do something that you don't like sooner or later. Are you doing this because you think it's the best practice, maybe that makes sense for certain workloads but for others, it slows you down because you're not able to build on top of highly differentiated services in some cases? Not every workload needs that as a design objective. That doesn’t make sense for an awful lot of stuff. It's life sustaining, yeah, by all means, go for that. if it's something that just ties back to, well we read it in Gartner and it's very important that our nonsense Twitter for pet service be up even when AWS is broken and on fire, maybe that’s not necessary, maybe it's really expensive, maybe the internet is better if your crappy service is down for a few hours. I mean, there's a lot of different things that tie into this.
Ernesto: Yes, that’s correct. The important thing is to know in advance. To make an informed decision as you enter AWS, at least you know, this is what I signed up for and I'm okay with it. The worst thing that can happen is really to be surprised by it further down the road if you decide to move out of AWS. That’s an important thing. That’s related to vendor lock-in. there are a number of other factors that you have to consider before choosing a particular service and even if it's a service that you're familiar with, so let's say EC2 or Lambda, very popular services that a lot of people are familiar with.
You still need to evaluate that particular service in a lot of different areas and make sure that it's going to support your particular business case. So I recommend doing this process for every service that you include in your architecture even if it's a service that you are entirely familiar with because again, you have to evaluate the service within the context of a particular business case. There are things like the available regions, for example, not all services are available in all regions. There are areas related to performance and scalability like service limits for example. There are a number of service limits in AWS. Some of them you can increase if you submit a support request, but some of them you cannot. You have to be aware of those service limits as well. Again, as they relate to that particular business case.
Those are some examples, right? The scaling, how does scaling work in this service, is it done automatically for me, do I have to explicitly configure it somewhere, or is it going to be difficult to provide some sort of automated scaling mechanism. Those are things that you also need to be aware of. What are the failure scenarios like, what can go wrong and if something goes wrong, how's it going to be remediated?
Those are things that also is just important to go through those scenarios. Again, even if it's a service that you're familiar with because again, it really depends on that particular business case and that makes it more relevant. There are a number of factors right? There's of course authentication, security, there's encrypting your address or not, those type of things. There's also one area that I really like about AWS, in the past two years, AWS has really developed this concept of what I call built-in integrations. Now you see there's a big ecosystem of services that integrate with each other very easily.
A good example of that is CloudWatching events. You can basically detect all these events that are going to happen in your AWS resources and you can trigger responses for those events. Those are built-in integrations that are very useful at Lambda itself as a service. It has a lot of very cool integrations with a number of services out there. That also increases the potential for a number of use cases, it simplifies in many ways how you out automate certain processes. Those are things as well that are important to consider when evaluating a particular service. What are the built-in integrations that are out there?
There is a monitoring as well, that's an important part. What metrics are available for that particular service. For example, EC2. Yes, it has a number of very useful metrics but, CloudWatch does not publish memory metrics. It might be the case that is necessary that you monitor memory and you have to be aware there are ways around that, you can still get memory metrics if you use the collect the plug-in. You just have to be aware of all the different things that need to be in place in order for you to use that particular service in an optimal way and again, I'm just trying to emphasize this which as it relates to a particular business case. So yeah, that's basically I think I expanded a bit on all the different areas that I find relevant when it comes to choosing a particular service.
Corey: I think you're largely right on this. It's one of these areas where to some extent, you find that there's a strong argument coming, you have to be multi cloud according to a variety of different partners out there.
Ernesto: Do you have any question on this area?
Corey: I may be overly cynical on this but it feels like to some extent, part of the reason and rationale behind that is that if you're pure all in on a single provider, be it AWS or anyone else, there's less of a story for partners. I guess my position out of this to some extent, there are an awful lot of partners out there that I feel that their entire business is already in Amazon's crosshairs as far as partnership goes. As a consultant, I'm not an Amazon partner and I use that as a bit of a selling point for my specific market. Where do you stand on the idea of I guess partnering with Amazon based upon what you see historically at as well as currently?
So it feels to me and this is overwhelming cynical that the reason a lot of companies are pushing for a multi-cloud narrative is because even as an Amazon partner or a partner with any of these large cloud providers, if you're all in on a particular provider you probably don't need too many partners to help you out whereas if you're disambiguating between multiple providers there's much more of a story there. So to that end, I am not an Amazon partner what's your take on the entire program?