Disclaimer: This interview is for informational purposes only and should not be relied upon as a basis for investment decisions. In Practise is an independent publisher and all opinions expressed by guests are solely their own opinions and do not reflect the opinion of In Practise.

{audio:0:38:06} Can you share a bit of context to how and why containers came about?

{audio:0:38:16} We could go way back to Solaris zones, but we will start with Docker in 2015. This was just a nice way for developers to get this atomic packaging unit that had the binary for their location and also patched a bunch of the dependencies together to keep the applications runtime consistent, regardless of where it ran. It was picking up a lot of steam because it just made the developer lifecycle a lot easier. Basically, your code would always behave the same way because it has the same things in its environment continuously. 

{audio:0:39:06} This was just one of those projects that developers latched on to and just started using very heavily. They also started to realize what containers gave them in the sense that it made it much easier to deploy the same software in multiple environments. You can run the same thing on your on-prem server as you could on a cloud server, regardless of the configuration differences between those two environments. It gave them a lot of portability which was nice. As Dockers started getting popular and folks were considering it for actually running their production applications, there definitely became a need for a bunch of support systems around because you had dozens or hundreds of containers running at the same time and you needed some way to track the life cycle of all these things. Is it up? Is it down? When was the last time it was updated? Is it healthy? What other services is it related to? Which containers is it speaking to?

{audio:0:40:05} Out of that, we saw the rise of things like orchestration systems. In early days, it was Docker Datacenter, an Amazon ECS and Kubernetes after that. This was all tooling to help customers run containers at scale in production. It was really a game changer at that time, in terms of adoption.

{audio:0:40:26} Can you explain in more detail why exactly Docker and containers in general became so popular?

{audio:0:40:37} I think containers became so popular because it was just a huge quality of life upgrade for developers. You used to live in this world of, I am deploying my application to a server on premise and it has a certain configuration around it and that can just lead to different behaviors or maybe my app just does not work. That is confusing because, when I am running it on my EC2 server, it does work and it is fine so then I start to look at all the differences between the environments and what is causing the issue. 

{audio:0:41:10} Containers let you shortcut that whole process because it was this wrapper around your application code that included all of the things that needed to run. That meant that it would always run regardless of what system you are running it on. Docker provided this little bubble for your application to run within and it just was not disturbed by the settings of the app or the operation systems layer around the application. It was nice because of that aspect. It also gave you some nice things like declarative configuration of your application environment of the container itself. You could say, I want these three things when I do a Docker build, when I build the container, to makes sure those things are there. I get a very repeatable artefact out of that. I can take these instructions, give them to my co-workers, they can build the same Docker container and we all have the same results and copy of what this runs on. It really made it easy to handle packaging, collaborations and so on.

{audio:0:42:20} But the code still runs on EC2 or the underlying server? 

{audio:0:42:24} Exactly, so the code is still running on a server; it is still being executed by that same processor. It is still being run within the operating system but it is using a couple of underlying operating systems to give the code some high selection. It looks like it is running on its own shell, essentially.

{audio:0:42:45} How did that change the way apps were built and how developers would approach where to build them?

{audio:0:42:58} I think it was very synergistic with the growth of the cloud. The patterns that enabled, in terms of horizontal auto scaling, deploying software very rapidly and continuously, the patterns that containers offer were very similar to the patterns that customers were applying on the cloud already. Auto scaling was a thing already on the application layer and it was an obvious fit. There were a lot of container workloads on-prem but from our perspective, a lot of those were being containerized so they could be moved to the cloud more easily. It was great for the portability.

{audio:0:43:54} Could they move workloads around more easily once they used containers? 

{audio:0:43:56} It depends. The portability aspect was huge. I could test the software on my laptop and make sure it is going to work both in my on-prem and in my cloud environment. I think it just made folks more willing to launch something in the cloud because they have the ability to fall back later to their on-prem, using a container if they wanted to.

{audio:0:44:22} What about from AWS to Azure or cloud to cloud?

{audio:0:44:27} You do see some of that and it is definitely one of the reasons. I think that is a promise that Kubernetes made early on. It is one orchestration system it can run anywhere and that allows you to move applications between different clouds with ease and I think it is true, to a degree. You can definitely take your Docker container and your Kubernetes services that are running in EKS and you can go and run them in GKE. I think the reality is that there is still quite a bit of configuration differences between those systems on different clouds that it is not quite as seamless as you would hope.

{audio:0:45:05} There are actually some companies in the business of trying to smooth over those differences and make it more easy to port things across different clouds. In general, it is true but it is not 100% seamless. To give a more tangible example, you might need a different configuration in Kubernetes to use a GCP load balancer versus a kWS load balancer, depending on which load balancer type and how you want it configured. There is also a very common pattern of, within Kubernetes, you integrated with managed cloud server that your cloud provider offers and those integrations look different depending on which cloud you are running in. There is still a bit of a porting struggle but, in general, it is definitely easier than it was previously.

{audio:0:45:50} Although the containers make it more portable, you cannot just pick it up and lift it and press play on GCP. There is still configuration required to make that change.

{audio:0:46:07} You could do that if it was a self-contained application. If it was just the container itself, then there is really no friction. If we are still production workloads that are integrating with other services that the cloud provider offers, you are still going to use a database somewhere, you are still going to use the load balancer in front of that application probably; you might still be using a Blob store. You still have that sort of friction and you cannot extract away those differences between clouds.

{audio:0:46:38} Can we take a step back and just explain the history of EKS at AWS?

{audio:0:46:51} With EKS, I think at that time there was already Amazon ECS which was like the in-house developed container orchestration system. ECS was a very popular service and you saw a lot of customers adopting it. It is still a fairly popular orchestration system but it only allowed you to run AWS containers on EC2 and it had very opinionated AWS integration. The load balancer was always going to be the Elastic load balancer from AWS. Kubernetes came along, I think originally out of Google, and it was really gaining a lot of steam in the open-source community and customers were running it themselves on EC2 or GCP. One of the reasons they were doing that is because it had so many different integrations available. Basically, anything you wanted could run in Kubernetes. In comparison to using ECS and having ELB as your load balancer, on Kubernetes, you could choose to use the built-in Kubernetes load balancer, you could use the ELB from AWS and all these different things. That is the same story for everything else; there are a million integrations and a bunch of different supports.

{audio:0:48:13} It was extremely customizable as well. You could write all these plug-ins and extensions to it, whereas with ECS, if you wanted a new thing you had to wait for Amazon to implement that feature. Kubernetes is getting very popular for that reason. I think managing the actual cluster itself Kubernetes has a control plane for each cluster and that control plane is basically three API servers and a database that stores the state for the system and you had to manage that yourself.  It required some special expertise; it was not really a value add for your company to be spending time managing something like the Kubernetes control plane.

{audio:0:49:02} That is where services like EKS and GKE came in, where they just offloaded a lot of the operational components; the stuff you would have to do day to day but didn’t really add any value to your company. EKS started by managing the control plane; managing the API servers, managing XED, the database, doing things like backup and restore, handling things like upgrades and security vulnerability. All that was taken care of for you so you could just focus on using Kubernetes and deploying your applications to it, instead of actually doing the operational work which consumed quite a bit of free cycles for those customers.

{audio:0:49:44} Which type of customers adopted EKS? 

{audio:0:49:53} It was representative of EC2 as a whole. You see the whole spectrum of customers. I think, on the really small end, Kubernetes had a bit too much complexity for certain customers to adopt it so certainly, I would say it skewed a little bit larger. If you are a solo developer, you are probably going to look at something like Elastic Beanstalk or maybe just run on Fargate and ECS because you do not need a lot of capabilities. Certainly, in general, there is a mix and you see companies of all types.

{audio:0:50:31} Why did larger companies not do this themselves then?

{audio:0:50:35} Some of them did actually. Some of the largest companies were running Kubernetes themselves. They had a team, internally, which was dedicated to that. Some of those companies were, ironically, some of the biggest advocates for Amazon to have a managed Kubernetes service because they had seen, upfront, the operational burden that it imposed on them.

{audio:0:51:12} How sticky is EKS? Let’s say I’m an enterprise using EKS and I want to switch to GKE or bring it in-house, what is the process?

{audio:0:51:15} EKS and GKE are all offering the open-source Kubernetes distribution. It is the same software but that is the benefit of it, as well. The customers that are using these services want to make sure it is the open-source Kubernetes, specifically for the reason you just called out. They want the portability aspect. I think that is always a capability and customers view it through that lens. We have this cord we can pull to change cloud vendors and be not locked in or something like that. But I am not sure that that ever happens in practice. You could do it, but I think what ends up happening for most customers who are multi-cloud is, some workloads run in AWS on Kubernetes, some workloads run in GCP on Kubernetes and you are not really using Kubernetes as a deciding factor. It’s more of a table stakes expected thing to be there. 

{audio:0:52:26} Instead, you are making decisions on workloads or where you invest based on the quality of the platform and the cloud provider. I think customers initially thought of it more as, we are just going to move workloads all over the place and there is still a lot of burden to doing that. As I mentioned earlier, you still have different integrations you have to care about; there are still nuances to these platforms that are different.

{audio:0:53:01} What is the burden? Is it plugged into other services that are using AWS? Or is there a specific configuration required if it is run on EC2? What is making it difficult?

{audio:0:53:12} It is certainly both. Basically, there is this idea of a platform that you build on top of Kubernetes. By that I mean they have a stack of software that developers can use, inside of Kubernetes, to flesh out their application. They have got a database available; they have got a load balancer option available; they have got a security solution available. Some of these things are native AWS services; some are using these Kubernetes controllers to call and provision AWS services. These platform teams are building these workflows for developers to use. A lot of it just has logic built in that is specific to EKS or does have a dependency on specific AWS servers. The same applies to GCP and EKS.

{audio:0:54:03} There is still a consideration of the environment of the cloud provider around the Kubernetes cluster and it is not completely isolated away. You could take an approach where everything is completely cloud agnostic and you are only using open-source tools and you are doing it specifically to make sure that you could get out of there as quickly as possible. I think we found that not to be the case and you tend to take advantage of what is available in AWS, and what is available in GCP if it is there because it’s, ultimately, a lower burden on your developer.

{audio:0:54:39} What would you estimate the customer churn of EKS to be?

{audio:0:54:47} I think it was very low. Customers were still in the phase of investing more and more in Kubernetes and it was all additive workloads. There were some customers who were growing Kubernetes on-premise as well as in the cloud but you also saw a lot of net new workloads landing on Kubernetes for the first time, maybe within an existing customer who already had a big EC2 footprint just deciding everything here forward is on EKS or moving to Kubernetes for everything. You did see all shapes and I have some confidence that is still the case and that Kubernetes’ usage in general is still growing and these customers are growing it, maybe not just on AWS, but on other clouds or on-prem too.

{audio:0:00:01} Can you help me paint a picture of how large enterprises typically use EKS? For example, Delta Airlines just publicly released they're going sign with AWS, but they didn't release specifically what workflows they are moving. Can you describe for a client like Delta or a big airline, how would they typically use EKS?

{audio:0:00:33} I think there's a combination of different patterns that we saw happen pretty regularly. In the case of Delta, they're a large enterprise, and it's a fairly safe assumption to say that they have some on-premises workloads. It's really common for these customers to try to move a lot of this to the cloud. And Kubernetes is a really common vehicle for that. For large companies like Delta, they are obviously already very tech savvy in many ways. There's probably a series of net new investments that are going to go directly to Kubernetes and this is a pivot we saw a lot of customers make. They might have a lot of existing Cloud infrastructure or stuff on premises, but who cares? We're just going to put everything new on Kubernetes because that's what we think our platform of the future is really going to be because we have this mobility.

{audio:0:01:30} Then there's a third aspect and some net new capabilities that customers can take advantage of by using Kubernetes. For a lot of large enterprises, it was a great way to get into the ML space, doing machine learning, leveraging GPUs. Kubernetes has great support for that and a lot of customers saw Kubernetes as the channel for them to invest in that more heavily. We can go back and dig into any of those three, but I'd say that those are probably all happening at a company like Delta, who's saying EKS is a big part of their strategy going forward.

{audio:0:02:14} If I'm the Delta CIO, who makes these decisions, that lift and shift via Kubernetes, how do they decide whether it's EKS or GKE?

{audio:0:02:31} I think it just depends on which cloud platform you decide on. I'm not sure that Kubernetes ends up being the differentiator for the cloud platform. It seems to be more about, I'm going to use the one that's available in the cloud platform that I decide upon. It's more of a checkbox. It's a table stakes feature, and you want it to be mature, you want it to be good. But over a certain degree of maturity, you're really looking at the rest of what the cloud platform offers, and how integrated it is with my Kubernetes. In a lot of the early days, we'd see companies make decisions based on the maturity of the Kubernetes platform, when EKS was really early. I think there were some cases where people said, we're going to go with GKE until EKS is a little bit more mature, because it just doesn't have the capabilities that we need yet. Or, we're not sophisticated enough to operate EKS, because we still had to do things like manage the worker nodes. But after a certain point of maturity, that no longer became an evaluation. It was more about, we're going to use EKS. We know you've got a lot of large customers using it similar to us; we have a lot of confidence in it and we prefer to go with AWS for these other reasons anyway. It was more just a component of the overall cloud strategy than it was the deciding factor any longer.

{audio:0:03:59} What, typically, is the deciding factor?

{audio:0:04:03} If I'm Delta, there could be a variety of things. Some of it comes down to, do you have data centers in every region that I need? Or maybe there's local zones in certain locations that are beneficial to me, like edge computing is really beneficial. In some cases, it comes down to relationships at the executive level, and how good the deal structure is. There are all these different elements, but there's definitely a lot of technical drivers as well. One thing that I think can't be understated is when you're building a team of developers, and you have this operations base of talent in your organization. 

{audio:0:04:54} There's a huge consideration for which cloud provider they already have experience with, and a lot of folks bring a lot of AWS experience. I think the reason why Kubernetes is so popular and such an important component of the stack, is because you can find folks out there who have a lot of Kubernetes experience. If you try to push an alternate container framework, you have folks struggling to ramp up and become productive on these new things quickly. There's a lot of different reasons for selecting AWS and a lot of it comes down to platform maturity. As a consumer – let’s take an airline as an example – there's so many case studies and references and patterns for me. to be successful there because there's other airlines already doing it. They're talking about their use cases and there's AWS publishing case studies about how, let's say, American Airlines was successful. 

{audio:0:05:52} For example, Delta mentioned they're going to adopt Amazon Connect, which is their customer service contact center offering. Would it be like these other services – more specific platform as a service offerings – that would be interesting for Delta to move a workload? Then they'd adopt EKS to do that, because AWS is offering the best Amazon Connect service?

{audio:0:06:18} Yes, that's exactly right. Sometimes there's just happens to be a unique service that fills a niche for a customer that I really don't feel like I can get anywhere else. Maybe as part of my migration, I wanted to offload my legacy customer service operations, and AWS had the most compelling factor, most compelling feature set in that domain. That does happen as well. A lot of times, that was the icing on the cake. I think that there's still a lot of brand recognition and this sense of stability and reliability with AWS that goes very far and some of the additional value with very niche services that fill a specific requirement I have or maybe that's the tip of the spear. I think a lot of the bulk of the reasoning still comes from those operational and maturity components.

{audio:0:07:19} Which can be based, like you said, on the technical elements of the data center quality and speed and latency of being in certain regions, which is the core. Once you get over that, then it's maybe the odd Amazon Connect offering that leads to EKS and other services. 

{audio:0:07:36} Yes, exactly. I've seen deals progress from both directions. I've seen deals progress because the customer decided they needed DynamoDB, to use a very generic example, with Connect being a very specific one. There are certainly deals that happen, because Amazon has some unique service and customers feel like they do it really well. Again, many of those deals start from the other direction, which is just the reputation of Amazon and having all of the infrastructure fundamentals that I need to be successful. Bonuses are the extra services that remove some heavy lifting for me.

{audio:0:08:12} Going back to the Delta CIO, he was the one who made a quote in the public release for Delta partnering with AWS. What is the endgame here? Do you see him, or CIOs from big companies like Delta, having Amazon that serves a kind of operational part of Delta's business? They run on EC2; they have Amazon Connect. They lift and shift with EKS, and then maybe they choose Azure or Google for another part of the stack, and they will use GCP for that part. They're happy to be multi-cloud because of the benefits. Are they going to slowly start shifting over these different workloads to different cloud providers when and if it makes sense in different parts of the stack?

{audio:0:09:05} Yes, I think that's right. There are a couple of really common reasons why customers start going multi-cloud. Firstly, there are regulatory reasons for it. In Europe, regulations compelled banks to have multiple cloud providers. Sometimes, in the case of an acquisition, the acquired company has a stack on a different cloud provider, and you just integrate that because the migration burden is too high. I think it's a prudent move by many CIOs to have a multi-cloud strategy. It may not be so much that you want to actually like failover between clouds or actively move workloads, but to maybe have a distributed footprint, so you don't feel like you're too concentrated on one, should something go wrong. 

{audio:0:09:49} It's definitely a face-saving maneuver. I think this is where you see a lot of the success that HashiCorp has had because they do provide those even more generic abstractions than something like Kubernetes, that do allow you to be multi-cloud and pivot really easily. HashiCorp, as a company, is predicated on the idea that more and more companies will go multi-cloud to distribute their risk footprint and they've been correct so far.

{audio:0:10:15} What was the go-to market strategy for EKS? 

{audio:0:10:24} A lot of the value that AWS was communicating for EKS was that operational competency, just basically saying, we're the best at operating, whatever it might be. and we have a bunch of unique expertise around Kubernetes as well. There's a lot to be said around the very solid primitives that exist in Amazon. For example, how they think about managing databases at scale; etcd behind Kubernetes is a database. And the same ideas that allow them to successfully manage millions of RDS databases is the same thing that allows them to successfully manage at etcd. It’s about communicating that they are very good at it and building trust around like the operational practices that are in place. Just again, that high bar of engineering expertise and being specific about certain failure modes. If this happens, this is how we respond to this; this is our practice for dealing with security breaches. Here's all the things that we think are important and that you no longer have to do. Additionally, there's the Kubernetes expertise in terms of running it as an AWS service. 

{audio:0:11:40} There's also the Kubernetes expertise in terms of supporting the software itself, because it's an open-source tech. Things are always changing; you're always having to respond to bug fixes, and kind of deliver these consistently and be very quick with that. To be a good citizen in the Kubernetes community, you also want to be taking patches and committing them back upstream. Customers want to know that you can take patches from upstream and apply them to their clusters quickly. 

{audio:0:12:11} Also, if you discover something, you can roll it out to the rest of the Kubernetes project to make sure that what you're running in EKS, is still the same software that's being run upstream. Customers really want to maintain that upstream compatibility angle. Granted, there are differences in that some of the patches on EKS are only applicable to EKS, or AWS, and aren't applicable upstream. There are some slight differences. But customers want to make sure that things are always compatible between upstream and what's running in EKS. The last element of EKS is, there is a distinct effort to make sure that EKS is integrated into the rest of the AWS ecosystem. Building these integrations with other services, like a set of controllers that allow you to provision any sort of Amazon resource from within Kubernetes, and then attach it to your pods and build it in as part of your stack. That integration component is really, really helpful.

{audio:0:13:15} Integration with other micro services, but specifically, so your microservices can take dependencies on RDS, for example. As a Kubernetes developer, I never have to leave the Kubernetes command line to provision an RDS database and attach it to my pod. I get these nice integrations where AWS is specifically encouraging you to configure and attach AWS services that you want to build your applications from within Kubernetes. Those are the three, I think. It's operational, in terms of the AWS service and the architecture. It's this open-source expertise of managing Kubernetes itself and being able to contribute back to the community. Then a third is AWS integration; that real native set of tooling that's just available to you as a Kubernetes dev.

{audio:0:14:07} Wouldn’t GKE and Azure offer the same level of integration with their services for this?

{audio:0:14:14} Your point being is, are those already key differentiators? Or are any of those so different? There's definitely a high operational bar, which I know in the past, there's been customers who maybe ran into problems with GKE or EKS and just said, we don't know if we can trust them anymore. Those might be old issues. Maybe that's not true anymore, but that certainly could be a factor. But again, this comes back to the selling. AWS is a platform; it's a cohesive option. EKS is like a very nice cornerstone of your stack; it's a very reliable enterprise grade Kubernetes offering, but is it really different in terms of what it offers you? No, it's open-source Kubernetes distribution and I think that that's actually part of the value prop. If you made EKS too different, if it wasn't upstream Kubernetes, customers wouldn't buy it. They'd be much more hesitant. They don't want something that's Amazon lock-in, or something really peculiar to Amazon, that wouldn't be aligned with the services goals. The service wants to provide upstream Kubernetes in a way that's just well-integrated with AWS and operated to a very high degree of competency.

{audio:0:15:39} There's never really arguing between, choose me at EKS, because we're better than GKE?

{audio:0:15:46} You see some of that, and maybe it's in small things like, we're delivering Kubernetes versions more quickly, we patched this security flaw more quickly, or we offer some better workflows for integrating with different services. But yes, I think that the value prop is not too different than the value prop of core AWS. At the end of the day, this is seen as just core compute primitive. It's in that same family of EC2, ECS; all these things that you would use to run your applications just at the base layer. It's almost like looking at the EC2 versus the GCP VMs. At some point, they are very similar in functionality, but there's minute differences that may swing you one way or the other.

{audio:0:16:36} But it's great from a business perspective, because it's almost like, migrate from OnPrem and you just have every single possible service to provide them in transition. EKS, Amazon, and obviously, the core compute layer, which is the foundation.

{audio:0:16:57} I think there's a pattern and this is the first pattern I was talking about that you would see with Delta, the lift and shift pattern. What we would observe commonly and actually encourage customers to do, because it made the most sense for them usually, was to do that lift and shift. You containerize an application that's been stuck at a data center and you move it to EKS. First, you get good at operating this thing as a container and as a Kubernetes service, there's some adaptation you have to do there around your process. Beyond that, what you can actually start doing is, when you refactor your app, it makes it much easier to take the small components of your application, break them off into their own containers, make sure everything's still communicating with some service discovery. You would see in parallel, this lift and shift procedure happening, and you would also see this net new investment happening. Customers would start new projects in like native microservices patterns. But for a lot of these, there was kind of an ongoing lift and shift and then refactoring process that would take years.

{audio:0:18:00} But what it allowed them to do was just unpin themselves from the physical hardware, the data center that they'd been stuck in for a long time. Ultimately, it was very, very productive for them. Some of the customers would keep on premise Kubernetes installations, some of these companies would have interesting edge compute situations. Maybe they needed to be in the airport, I don't know. You saw some companies doing things like running Kubernetes, like in locomotives. You would still see on prem Kubernetes but, the majority of the time, you would see them try to get out of these existing data centers and just really have some flexibility in where stuff was running. The lift and shift let them start down that path of kind of, firstly, getting out of the data center, and then, secondly, moving to something that was a little bit less monolithic and gave them more flexibility.

{audio:0:28:27} How did you think about pricing?

{audio:0:28:35} Earlier, I alluded to this idea of, are services going to be priced on value, or are they just going to be something that is an induction to EC2? EKS did have a price for the control plan and that pricing was comparable to what GKE was at that time, I think; maybe a little cheaper. But that wasn't really to make money. The idea behind that was more just defensive. We're spinning up infrastructure on your behalf, and it's just basically to cover costs. The idea there is really that EKS would drive EC2 revenue. It gives customers a new way to adapt more EC2, can help customers consume sort of those niche instances, like GPUs for machine learning workloads, for example. But in general, it just helps customers increase the consumption and continue to drive EC2. And so that is the approach; there's no additional cost on top of the EC2 that you run as part of your EKS cluster. 

{audio:0:29:35} It was seen as, there's this nominal fee for the control plane because it's just covering costs for what we're running on your behalf and the rest of it is just all EC2. There's a few other services like that, and there's a couple of other approaches. You see RDS do something similar, but there's a little markup on top of the instances for the management that they're doing, and for the database expertise. There's a little bit of value add on top of just pure EC2. But at the end of the day, EKS was really a compute service and we wanted customers to consume more, compute through that and make it as non-disruptive as possible to do so.

{audio:0:30:20} Is there a separate P&L for EKS and these services? Do you have to run a profit and loss individually? Or is it, like you said, for EKS it was almost under EC2?

{audio:0:30:35} Primarily, yes. You're looking at what your contribution is to EC2 and you look at what customers are consuming through EKS? You can see that this instance was launched and attached to this EKS cluster, so you would see, what's the resulting EC2 usage? That's how the container services were metered. For ECS and EKS, you'd look at how many instances, essentially, were being driven by that service.

{audio:0:31:07} That fee that you charge for management of EKS would cover the cost of running EKS and the overheads in Amazon and the profit is a portion of the EC2 revenue and margin?

{audio:0:31:23} Yes, that's right. The control plane costs were not really a big source of revenue; it was nominal. It really comes down to, are we driving a lot of EC2? That was what you're measured on. EKS was good at that; it did lot of customers.

{audio:0:31:39} What about other stuff like Redshift; would they have their own P&L? 

{audio:0:31:46} Definitely; a GM of each service manages P&L. As an example, you definitely wanted to make sure that we're charging this control plane fee. We're charging this control plane fee; let's make sure it's actually covering our costs, or we're not losing a lot of money without being intentional about it. You would be responsible for the growth and the revenue of your EC2 consumption. You would take goals based on how much EC2 you would drive in each quarter and that was sort of your P&L. How much revenue am I driving? How much am I influencing? That was more your focus, rather than making a certain amount of margin on the control plane. We dropped prices on the control plane as well, just because there's actually more profitability here on the control plane side that we don't actually need. 

{audio:0:32:48} AWS will make those decisions. We have a little bit of wiggle room here; should we pass the cost savings on to customers or is that something we want to take as profit, and in this case, it was a cost savings. That's a continuous goal too. If you have something that you're charging money for, do you have an opportunity to reduce prices, while retaining your margins by doing either cost savings efforts on your side, moving to new instances behind the scenes, or whatever it might be, things to get your costs down? You can actually reduce price continuously as well, which is always an interesting challenge.

{audio:0:33:20} Let's say, again, I'm Delta Airlines; I want to move some workloads over, running an EC2 via EKS. I want to switch out. What are the egress fees, typically, the cost of me moving away? 

{audio:0:34:07} In terms of taking your containers and deploying them elsewhere, nominal; that part is not really going to cost you anything. The containers are generally pretty small, in the order of a couple of gigabytes, maybe on the high side. You could actually pull your containers from Amazon's Container Registry and deploy them to Google without problem. I think that the question comes down to, what sort of data footprint do you have? If you have a lot of data – petabytes – in S3, for example, you have to ask yourself, do I want to move this data out of S3 to GCP so I'm consolidated on one cloud provider? Or do I want my data on one cloud provider and my compute layer on a different cloud provider? That adds a lot of complexity, definitely additional latency, struggling performance. That's where the cost for S3 starts to come into play because it's free to push to S3, but you pay to store it and then you pay to retrieve it. If I'm moving petabytes out of S3, it's both expensive in terms of time and effort; probably more in terms of time. Then I'm paying to retrieve that data and put it elsewhere. Those sorts of moves can be expensive if you have a large data footprint. Have you heard the term 'data gravity' before? That's where that comes from.

{audio:0:36:04} Do you ever see customers actually taking their data out of S3 to switch?

{audio:0:36:07} I can probably count on one hand, the amount of times I've seen that happen. It's very expensive for maybe marginal benefit. It's tough to quantify really what we would get from that. Maybe you would have to have been burned by S3, in terms of outages or something, something really dramatically bad had to occur. S3 is just so stable and reliable. It must be something almost personal to decide to take petabytes out and pivot. Data gravity is a big thing. Once you've invested and you have your whole data footprint on a specific provider, chances are, that workload is going to stay there unless something really has changed for you.

AWS: Containers, Kubernetes, & EC2 Stickiness

Former Senior Manager at Amazon Web Services

inpractise.com/articles/aws-containers-kubernetes-and-ec2-stickiness

Executive Bio

Former Senior Manager at Amazon Web Services

Interview Transcript

What about from AWS to Azure or cloud to cloud?

What, typically, is the deciding factor?

Related Content

AWS: Culture, EC2, EBIT Margins & Market Share Outlook

Former Senior Manager at Amazon Web Services

Amazon Web Services: EC2 Graviton Strategy

Former Senior Manager at Amazon Web Services

Amazon Web Services: Data Center Economics

Former Director at Amazon Web Services

AWS Series: Kubernetes & The Portability Illusion