Episode Summary
Andreas Wittig is an author, entrepreneur, and AWS cloud architect and software engineer at widdix, a tech firm based in Germany. He’s also a senior consultant at tecRacer who focuses on AWS. Andreas recently co-wrote Amazon Web Services in Action with his brother, Michael, and together they run cloudonaut.io, an AWS-focused consultancy. Among other career highlights, Andreas once migrated the complete IT infrastructure of a leading German bank to AWS.
Join Corey and Andreas as they discuss both of their journeys to AWS, how Andreas gets his ideas for AWS-inspired content, why Andreas thinks Fargate is a great tool for deploying applications on AWS—and why it’s even better than Lambda in some instances, the inspiration behind the Wittig brother’s new book, the two promises of Global Accelerator and when the tool is particularly valuable, additional AWS services Andreas believes don’t get enough attention, the concept of “infrastructure bootstrapping,” and more.
Episode Show Notes & Transcript
About Andreas Wittig
Andreas Wittig and Michael Wittig are freelancers, entrepreneurs, and authors. As freelancers, they are training, coaching, and consulting their clients on all things Amazon Web Services (AWS). In their role as an entrepreneur, Andreas and Michael are building SaaS products. The brothers have published two books Amazon Web Services in Action and Rapid Docker on AWS and are blogging at cloudonaut.io.
Links Referenced
Andreas Wittig and Michael Wittig are freelancers, entrepreneurs, and authors. As freelancers, they are training, coaching, and consulting their clients on all things Amazon Web Services (AWS). In their role as an entrepreneur, Andreas and Michael are building SaaS products. The brothers have published two books Amazon Web Services in Action and Rapid Docker on AWS and are blogging at cloudonaut.io.
Links Referenced
- Twitter: @andreaswittig
- LinkedIn: https://www.linkedin.com/in/andreaswittig/
- Company site: https://cloudonaut.io
- Books:
Transcript
Announcer: Hello, and welcome to Screaming in the Cloud, with your host, Cloud Economist, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.
Corey: This episode is sponsored by CloudZero. CloudZero doesn’t believe me when I say that trying to make your developers care about cost is a waste of time. Yet, they still sponsor my podcast, so here we are. Their platform is designed to help SAAS companies understand how and why their costs are changing, and lets easily you measure by things SAAS companies care about like cost per product or feature. Also, they won’t make you set up rules or budgets in advance, but will still alert you before your intern spends $10,000 on SageMaker on a Friday afternoon. Go to CloudZero.com to kick off a free trial. That’s CLOUD Z-E-R-O dot com, and my thanks to them for sponsoring this podcast.
Welcome to Screaming in the Cloud, I'm Corey Quinn. I'm joined this week by Andreas Wittig of cloudonaut. Andreas, welcome to the show.
Andreas: Thanks for having me, Corey.
Corey: You and your brother Michael are fascinating folks. You're freelancers, you're entrepreneurs and notably to the time of this recording, you're authors. You are the voice behind cloudonaut, which is fundamentally the thing that resonates throughout the community side of the ecosystem. But you're also doing a fair bit of consulting work through your company Widdix or Widdix. That's a “w” in front, but I'm not sure how it's pronounced.
Andreas: Yeah, so it's Widdix. Yeah, that's absolutely true. Our story actually is we started as software engineers and Michael and I ended up working in the same company, and we were looking for a way to get our software out to the world, to deploy it in a professional manner. That was actually hard, that time. Of course there was a single machine and some server rack, and deployments go wrong every now and then, more often than they actually deployed successfully. So we were looking for a solution and that was when we found out about AWS. This is now six years ago. Since then we have gotten deeper and deeper into that ecosystem and learned a lot over the years.
Corey: I first started doing my ridiculous newsletter about three years ago and one of the first things I started seeing when I was doing all of my, I guess, dog and pony show was a lot of references to the stuff that you and your brother had put out. It was fantastic to continue putting it into the newsletter. You were releasing a lot of interesting things. Midway through, about a year and a half in, I want to say, I realized that there were in fact two of you. As opposed to just one person who was super-productive, moving back and forth very quickly. So yeah, having two people does seem to make it easier, but if more or less whenever you folks wind up releasing something, it's shortlisted for inclusion in the newsletter, just because I very rarely see you writing anything that isn't useful or actionable to at least some subset of the population.
Andreas: That's a very great feedback. Thank you for that. I think what we try to do with writing on cloudonaut.io is we write about things that are out of interest for our self that are coming from the projects that we are working on. So I think that is actually the secret source behind all of that, is we write about the stuff that matters to us, to our clients and yeah, write blog posts out of that.
Corey: I guess I've sort of started doing the same thing and I don't think that I've been as, I guess, upfront about it as I probably should have been. I don't pretend that my stupid newsletter and accompanying podcasts are the authoritative list of what happened last week in AWS. For me, it's what happened that mattered. What happened that was interesting. There are times where I will cut three quarters of what's officially announced out just because it doesn't resonate with me personally. My biases absolutely factor into that.
I don't write a whole lot about Microsoft SQL Server. I don't write a whole lot about Kubernetes, largely because that doesn't resonate with what I'm working on. I don't spend time in those worlds for the most part. I guess from my own perspective, I don't see that that puts me in the place to be saying positive or negative, and too much commentary about anything that comes out in that space. Every time I dabble into it, I am immediately corrected loudly and violently by Twitter. So I try and stay in my own lane of things that matter to me. It sounds like you've been largely doing something very similar.
Andreas: Yes, that's absolutely true. But there's also funny stories, so sometimes I think I would never write about a certain topic. One of the topics for example is Oracle. That's a funny story. Oracle was really a topic that I was not interested at all, but recently I was actually migrating an Oracle APEX application to AWS and we managed to put that into a container and run it on Fargate. Now I'm so excited that we found a way to lift and shift this legacy application to a very cool platform on AWS, so that now I really want to write about Oracle on our blog. So sometimes the experience from our day to day work also changes what seems to be interesting to talk about in our writing.
Corey: I agree wholeheartedly. In fact, at the time of this recording, I am currently trying to figure out the best way to do something kind of obnoxious architecturally. The short version is I have a script that I run in various client accounts through assuming roles, but this script does run in my own account and it can take, in some cases, an hour or two to wind up completing. So that rules the traditional serverless story out of it, but I have to run it in every client account in every region because of course you can't globally query regions with AWS. Why could you? So it turns into a ... as you wind up with more regions being launched all the time and additional client work that needs to happen across a variety of different accounts ... like some customers are on a couple of hundred accounts easily ... that needs almost a step function sort of automation story.
I've been looking at Fargate with increasing interest, because it sounds like it's something that supports massive parallelization. As long as I can get this stuff stuffed into a container, and given that it is a single one-line script invocation with a few parameters to change, it seems like the right path. But other than that, I haven't gotten into it in any depth yet. So from that naive perspective, since real problems are always better than talking about theoretical ones, how would Fargate start to solve that problem? What is implementing something like this on top of Fargate look like? If that's a fair question. Because you know, getting free consulting under the guise of podcasting is always the right answer.
Andreas: Very clever. Very clever. Yeah, but I think that's a really cool thing to talk about. We are very big fans of Fargate since it was announced, and it has become a very convenient tool for deploying applications on AWS since then. Also integrations have become better and better. So the service maturity also increased a lot during the last years. Actually, I think of Fargate as a serverless compute service, like I think about Lambda but with less limitations. So we don't have the 15 minutes limitation. We don't have any limitations regarding our programming languages or libraries that we want to load. So Fargate is really easy to use.
The thing that you are talking about for example, so you have mentioned step functions and everyone knows that there is a good Lambda integration for it. So if you want to build workflows, you can use step functions, trigger Lambda functions and then build everything together, wire it together, with the state machine, and actually the same is possible with Fargate as well. So you can also trigger Fargate tasks or actually spin up containers with the help of a step function as well. And then the step function's state machine is taken care of, handling timeouts, retries and all of that in a similar way that it does with a Lambda function. So I think that's a very powerful concept to think about not only Lambda, but also Fargate as a serverless compute engine.
Corey: That absolutely resonates with my understanding of it. I think the piece that makes the most sense from my perspective when you say that, is the idea of, I have a thing, as long as I can fit it into a containerized task definition, I can throw it to Fargate and not worry about it. The premise of Lambda is similar, but there are enough, I guess, constraints around that where that doesn't map itself directly to every random bash script or Python script that I've beaten together. So as long as it runs in a container and I can hand it to Fargate, I don't have to think about it much beyond that. Is that more or less the way you see it?
Andreas: Yeah, that's absolutely true. So I watched a talk, I think it's four years ago, and it's still resonating with me. The guy in front of the audience said it doesn't make sense to run containers on AWS as long as our smallest resource that we can virtualize in the cloud is a virtual machine. So it doesn't make sense to operate your own cluster management on top of EC2 just to deploy containers to the cloud. Why are we doing that? I think he was absolutely right because a lot of people, us included, spend a lot of time and money on building clusters, container clusters on top of EC2, and that changed completely with the launch of Fargate.
Because now you can launch a container as you launch an EC2 instance, with the benefit that the container includes everything you need to run your application. You can run that on your local machine very simply, and your deployment pipeline as well. So it's a very effective tool to get your application, get your code, running on AWS. I think it's sometimes even a little bit more convenient than Lambda actually, because you can have your code running very easily on your machine deployed on AWS. That's the promise of containers, right? That's really working now because we don't have to care about the underlying infrastructure anymore.
Corey: From my side of the world focusing on cloud economics, I've noticed that Fargate has gone from interesting toy, but super expensive for anything non-trivial. There've been a couple of iterations on that. First we saw that it wound up getting a almost 40% price cut across the board, if memory serves, and suddenly it went from stratosphere down to the realm of reasonable. Then we took a step further and saw that the savings plans, their new RI replacement dingus, applies to Fargate as well. So, okay, great. If you commit to having compute in some form, whether it's on EC2 instances, it doesn't matter now which family, which region, or whether it's even EC2 or Fargate. As long as you're using compute, it offers it at a discount, and suddenly this becomes incredibly compelling just from a story of being able to execute applications that don't need to be shoved into artificially constrained environments.
Andreas: Yeah, absolutely. I think also savings plans really made Fargate much more competitive compared to running your workloads on EC2. So now we pay a premium on top of the EC2 price of about 20% to 30%. You could say that is a fair price for not having to deal with virtual machines anymore. So I absolutely think that this is a game changer for Fargate workloads because many of our customers told us, "Yes, Andreas, that's a very great idea. Fargate looks really cool, but why should we pay that much money for our infrastructure?" So I think that that argument is getting less and less important and so Fargate will in the future, I think, become more and more interesting. Also maybe let's see if ... Things that are missing is, for example, spot markets or spot instances is something that we don't have an equivalent with Fargate, but yeah, reserved instances, savings plans, we have that with Fargate now and I think that's a really cool thing.
Corey: Yes. We should also highlight that we are doing this recording of the week before re:Invent. So much of what we're about to say may not apply by the time this episode is published, but I have a sneaky suspicion that some of it will at least still be relevant. One challenge I've seen for some customers with Fargate as well is when they look under the hood at what it's running on from looking at CPU information, it appears at least to be running largely on C3 and M3 style instances, which is fine for an awful lot of workloads. But anything that's particularly compute-intensive, there's not the capability of using some of the newer generation of CPUs under the hood.
So if you have anything that's time-bound, it may not be the right fit either. But for just "run this script" I don't particularly care upon what you run it, and put all the answers into a queue somewhere," It's fine for that use case. What I think people also lose sight of is our time as engineers is never free. So the idea of, "Well, I could knock 30% off of that bill by running it on top of EC2 instances," and sure, if you're talking about multiple millions of dollars a year in spend, there's a terrific model for that and a market that makes sense, but for my toy example that I gave you, we're talking about, on a per-customer basis, something like $12 versus $20. Would I pay that marginal eight bucks in order to have this all handled for me? Hell yes, I would.
Andreas: Sure. I absolutely agree. So you don't have to convince me with stuff like that, but a lot of customers still need to be convinced...
Corey: Yes, yes. I probably should have warned you, we are in fact recording this. So some of my arguments are not aimed directly at you personally, but rather the people who are eagerly preparing to tweet at me about the conversation we're having right now.
Andreas: Okay, perfect.
Corey:
So you took it a step further. Rather than just mucking around with Fargate and other fun ways of getting dockerized things into production, you wrote a book on this that is going to be for sale well before the time that this winds up being published. So tell me about your book.
Andreas: Michael and me, we wrote our first book, Amazon Web Services in Action, and this year we decided it is about time to write our next book. We picked an area that we really liked and this was Fargate, and this was then why we started writing Rapid Docker on AWS. The book is, as the name implies, the focus is on rapid. So we want to make sure that the reader is getting into that as fast as possible, and can spin up the infrastructure that is needed to run an application. So a Ruby, PHP, Java and OTS Python application, as far as possible.
So we wrote a small book, it's only 120 pages. So it's to the point, it's only the relevant parts are in it. We also built a whole infrastructure as code example that really spins up the whole infrastructure that is needed. So it's consisting of EZS, Fargate, RDS, Aurora Serverless, and even the deployment pipeline. So everything bundled together. Of course monitoring is included with CloudWatch as well. We bundled that together so that as many people as possible can easily deploy their workloads on Fargate. So that is the intention of the book.
Corey: One of the challenges that I've seen in the past is that when you have books like this that are written around the easiest way to get from problem a customer has into solutions, whenever it starts talking about a particular service or path to getting to that outcome, it comes off, on some level, just at a cursory glance, "Oh, it's a sales pitch for service X." I understand why people think that. But having read through pretty much everything you folks have written over the last three years, you're not shills, you're not trying to sell services that aren't a fit for the task.
Your approach largely seems to mirror my own of, "What's the business requirement? Great. Now let's find the best way to get you to an outcome that satisfies that business requirement." So anyone who's thinking, "Oh, it's just a puff piece about an AWS service that they're trying to drive attention to," I disagree strongly. It's one of those services that suffers from not being the easiest to understand. Until people try something with it, it's very easy to overlook.
Andreas: Yeah. So you know, Michael and I, we always try to be also skeptical about the technology and the services that AWS announces. You might've read our reviews about services like Aurora Serverless or Global Accelerator, but we think with Fargate and a very simple setup with a load balancer, a Fargate run into containers, and an RDS Aurora database, we really think that this is a modern architecture to build on AWS that just focuses on simplicity. I think that's a very powerful tool if you're looking for something to get your stuff running as fast as possible without spending a month of engineering just for the infrastructure.
I think that's what a lot of people, a lot of developers actually are looking for. That's the focus of our book. Of course, it's not going into each and every detail, but we try to cover everything that is needed to also get the full picture and to understand how things work together. We also spent some pages on how to monitor and debug your infrastructure. So how do you find out about problems, how do you locate them, and how do you fix them? That is part of the book as well.
Corey: You bring up a couple of other interesting things that I've largely forgotten about. First, whenever I'm trying to deal with anything that even remotely touches on IAM. For example, one of my first resources that I go to is iam.cloudonaut.io. Because instead of playing hunt and check for two hours with the official documentation, I can drill down very quickly and see exactly what permissions are around a given service. It's incredibly useful and I can only assume that someone internally at AWS proposed this years ago and was immediately shot down on the basis of being too friendly to customers. Because this is hands down one of the most valuable resources whenever I'm playing around with IAM. The second most valuable resource of course is just great access to do everything, and I'm sure I'll remember to go back and fix it later.
Andreas: Yeah, I think we built the iam.cloudonaut reference when the documentation from AWS was not existent at all. It has gotten a lot better since then over the years. So it's getting less and less relevant. But I think still it's a very fast overview of all the IAM actions and resources and conditions that are available.
Corey: You also referenced something else that I thought was fantastic, which was your view of Global Accelerator. For those who aren't aware, Global Accelerator ideally improves latency and designing for failure around having traffic enter AWS's backbone, as close to the customer as possible, instead of waiting until they smack into the region they're going to, which is their default behavior. My AWS Morning Brief Thursday Networking in the Cloud show did have a segment on this that got some feedback, but your review of it was incredibly evenhanded.
It talked about the things it was great at and things that it wasn't terrifically great at, until I wound up reading this. My initial approach, that Global Accelerator was simply ... I'm not sure what it does so I imagined it makes the world spin faster, because Global Accelerator makes sense. Which in turn has got to be doing terrible things for climate change. At which point I was asked to please stop making that joke immediately because no one else found it nearly as funny as I did. You instead wound up doing some actual experimentation with it. Tell us about that.
Andreas: We are doing reviews of AWS services from time to time because I think it's interesting to look into the technical details of a service instead of just reading the marketing pages that AWS is putting out. One service that was announced at re:Invent last year was Global Accelerator, and it was on my to-do list for services to dive into a little bit deeper for now almost a year. Finally I found some time to actually look at it a little deeper. The thing is the promise of Global Accelerator are actually two promises. One promise is Global Accelerator will reduce the latency, the network latency from your clients to your AWS infrastructure. The second promise is you can actually build multi-region infrastructures and use Global Accelerator to route traffic to the closest and also healthy region that is available.
So I did some testing, and so the thing with multi-region deployments and routing traffic based on health checks, that was actually very easy and very simple, there was not much to have a look on. But the part of, "We're making it faster so we reduce latency," this was interesting because I actually wanted to measure what that means in reality. So what I did is I searched for a tool that allows me ... or actually a service that allows me to measure the network latency from all over the world to the AWS infrastructure, and then measure the latency to an application load balancer with and without Global Accelerator. And also compare that to CloudFront, which is actually a similar, or not very similar but another solution that is useful when you try to reduce latency and use that to dive a little bit deeper into the latency reductions that can be achieved with Global Accelerator.
Corey: When you take a look at that, do you think that it's a service that's worth using by default to speed up end-user traffic, or do you think that it's better reserved for specific use cases or specific problems that customers might see manifesting in their environment?
Andreas: I think the default service, if you run a web application that is doing something like HTTP, then you should probably have a look at CloudFront because there, you have the ability to cache requests at the edge. But if your workload is not HTTP-based or there might be other reasons to not use CloudFront, then I think it's actually very interesting to have a look at the Global Accelerator to just reduce the latency to your endpoints. As we all know, each and every millisecond that you can reduce typically helps in ecommerce, in gaming, in finance and so on. So it's probably valuable for a lot of scenarios.
Corey: What other services have you been seeing that you think don't have enough of a light being shone upon them? Again, we are recording this before re:Invent. So let's look back in time or I guess the previous year, before re:Invent hit. What do you think doesn't get enough attention, that people are taking far too lightly? It's very obvious from our conversation that Fargate was one of them. What else are you seeing?
Andreas: Actually today I played around with Amazon Connect, so the contact center solution, and I was really impressed about this service. I did know that this existed but I never used it before, and today I had a small use case to try it out and to build a small project with it. I think that's a very, very mature service with a really handsome UI. That's really something noteworthy because the UI is so easy to understand, you are creating a contact center within minutes and it's very easy to connect to different actions, everything. So I think that's another interesting service. Of course it's very niche, but definitely something that is interesting to have on the roadmap. Another one that I really, really like is Amazon Athena, the service that you can use to query data, unstructured data actually, that is stored on a tree with a SQL-like query language.
Corey: That is a fantastic point where the idea of having a SQL query language is, there are so many better ways to query things, et cetera, et cetera, et cetera. Yeah. Here in the real world though, everyone already knows it and no matter, even if you're not in the technical division, if you're a business analyst, you still know SQL or something very similar to it. So being able to have a language that is commonly spoken by the business as well means that suddenly you have an AWS service that's available to far beyond just the engineers or the "builders" as AWS likes to call them.
Andreas: Yeah, absolutely. I think Athena combines that, so the SQL engine and also the possibility to just store the data on a tree which is very convenient and very easy, also possibly cheap to do. Then query that data and analyze the data without, I don't know, spinning up a Redshift cluster or Elasticsearch cluster, something like that. So instead of that, you get a really easy way to analyze the data and you only pay for it on demand. So only when you run a query, you pay for the processed amount of data. So that is very handy. So I'm using it, for example, for the latency benchmark, so analyzing the results for Global Accelerator benchmark. I also use it for analyzing log files. So HTTP access logs, for example, or I'm using it a lot for also the EC2 network benchmark, for example. So there are many use cases where you just throw up some files on a tree and then use Athena to get some insights out of that.
Corey: I've been playing around with Athena a fair bit myself lately and there is some latency concerns there. The counterpoint is, the only thing to really get around that at significant scale that I played with has been Redshift. That apparently runs on burning piles of money because you need a lot of those to wind up paralyzing the queries appropriately.
Andreas: Yeah, absolutely. So Athena, and then another interesting service that relates to that is QuickSight. I know you always say they don't probably have any customers, but they have at least one.
Corey: I wish it were better than it is because I am burning a fortune on Tableau licensing instead.
Andreas: Yeah. They have at least one customer and that's me, and I'm building dashboards with QuickSight. I know it's not the greatest experience that you could imagine, but I think the big benefit to you is it integrates very well with Athena. And QuickSight has that in-memory cache that you can use to cache queries to your data, so you don't rely on a round trip to Athena and your objects on a tree every time. So that speeds up at least having a look at dashboards and visualizing your data a lot. So that helps sometimes with the latency for the queries running on Athena.
Corey: One other thing that I've ... Yeah, QuickSight is fantastic and I think that it is a service that has an awful lot of potential. If I'm being fully honest here ... because I imagine that people read my snark in the newsletter but no one listens to me when I talk into a microphone ... that I'm hoping that by my constant goading of QuickSight that they finally snap and a) fix it and b) bring me in to have a conversation. "All right. All right, jerk face. Here's exactly what we're doing. Tell me what ... how again this doesn't work for your use case," and then we will have an honest conversation and one of us will fix something. I'm not entirely sure whom, but it'll be a fun conversation.
Andreas: Yeah, that sounds great. I have something to add to that list as well, so...If you need some input...
Corey: Exactly.
Before we go, one more question for you. What do you do as a consultant? Because most of the stuff that I'm familiar with involves the things you're putting out into the world publicly. For example, the books, the write-ups, the blog posts, the reviews. What do you do that generates ideally the money that you use to feed yourselves? What's the consulting niche? What's it look like?
Andreas: Yeah, very good question. It comes down to maybe three main topics. It's technical coaching. We coach individuals or teams to get started with AWS or with a specific part of AWS. For example, containers on AWS or Serverless. That is one part that we do, we call it technical coaching. The second thing we do is infrastructure bootstrapping. We mentioned already that we have some CloudFormation templates open-sourced and we use them to spin up infrastructures very quickly. Usually we can get maybe 80% to 90% of the infrastructure that a project needs up and running with our base templates.
Then we only need to do 10% or 20% of the work to adopt these templates or to write new ones for the specific needs of a client. That is what we call infrastructure bootstrapping. This is typically something we do for something between one or four weeks. At the end we hand over the infrastructure, the documentation, and trained a team that is there in the future and taking care of that infrastructure. That is the second part. The third thing we do is we also ... I told you at the beginning, we are actually software engineers from the beginning. So we also write software or build stuff on AWS. So we do a lot of Serverless applications for our clients as well. That is the third thing that we typically do in our consulting business.
Corey: If people want to learn more about the various things you do, where can they find you?
Andreas: I think the best place to go is cloudonaut.io. This is our blog and it actually links to everything we do. So you can find our podcasts there. You find our blog posts also linked to our consulting business, to the book Rapid Docker on AWS. So that's basically the point that you'll find everything that we do, cloudonaut.io.
Corey: We'll definitely throw a link to that in the show notes. Thank you once again for taking the time to speak with me today. I appreciate it.
Andreas: Thanks for having me. It was a great pleasure.
Corey: Andreas Wittig, founder, entrepreneur, author, gadfly, et cetera, at cloudonaut.io and Widdix. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this episode, please leave it a five-star review on Apple Podcasts. If you've hated this episode, please leave it a five-star review on Apple Podcasts.
Announcer: This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever fine snark is sold.
This has been a HumblePod production. Stay humble.
