Screaming in the Cloud - The Wide World of AWS Consulting with Andreas Wittig

Episode Date: February 5, 2020

About Andreas WittigAndreas 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 ReferencedTwitter: @andreaswittigLinkedIn: https://www.linkedin.com/in/andreaswittig/Company site: https://cloudonaut.ioBooks:Rapid Docker on AWSAmazon Web Services in Action

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. This episode is sponsored by in the Cloud. platform is designed to help SaaS companies understand how and why their costs are changing, and lets you easily 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 cloudzero.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. Thanks for having me, 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 Wittix or Wittix. That's a W in front, but I'm not sure how it's pronounced. So yeah, so it's Wittics. And yeah, that's absolutely true. Our story actually is, so 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. And that was actually hard that time because there was a single machine and some server rack and deployments go wrong every now and then, more often than they actually deployed successfully. And so we were looking for a solution. And that was when we found out about AWS. So this is now six years ago. And since then, we have gotten deeper and deeper into that ecosystem and learned a lot over the years. 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 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. That's very great feedback. Thank you for that.

So I think what we try to do with writing on Cloud or Not.io is we write about things that are out of interest for ourselves, that are coming from the projects that we are working on. And 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. 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 podcast 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. And I guess from my own perspective, I don't see that that puts me in the place to be saying positive or negative, 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. Yes, that's absolutely

true. But there's also funny stories. So sometimes I think I would never write about a certain topic. So one of the topics, for example, is Oracle. That's a funny story. So Oracle was really a topic that I was not interested in 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. And 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. 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 the 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 hundred accounts easily, that needs almost a step function sort of automation story. And 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 that change, it seems like the right path. But other than that, I haven't gone 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 does 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. Very clever, very clever. Yeah, so, but I think you're talking, that's a really cool thing to talk about. So 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 and so the thing that you're 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, so actually spin up containers with the help of a step function as well. And then the step function state machine is taking 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.

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. I mean, 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? Yeah, that's absolutely true. So I watched a talk, I think it's four years ago, and it's still resonating with me. So 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? And I think he was absolutely right because a lot of people, us included, spent 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.

And you can bundle that on your local machine very simply in your deployment pipeline as well. So yeah, it feels very, or 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, deploy it on AWS.

So that's the promise of containers, right? And that's really working now because we don't have to care about the underlying infrastructure anymore. 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. And there have been a couple of iterations on that. First, we saw that it wound up getting an almost 40% price cut across the board, if memory serves.

And suddenly it went from stratosphere down to the realm of reasonable. And then we took it a step further and saw that 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. Yeah, absolutely. So I think also savings plans really made Fargate much more competitive compared to running workloads on EC2. So now we pay a premium on top of the EC2 price of about 20 to 30%. And I think that's, you could say that is a fair price for not having to deal with virtual

machines anymore. And 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... So the thing that I'm missing is, for example, spot to spot markets or spot instances is something that we don't have an equivalent with Fargate.

But yeah, so reserved instances, savings plans, we have that with Fargate now. And I think that's a really cool thing. Yes. We should also highlight that we are doing this recording the week before reInvent, so much of what we're about to say may not apply by the time this episode is published, but I have a sneaking 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 a looking at CPU information,

it tends to be, 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. And 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 in 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 $8 in order to have this all handled for me? Hell yes, I would. 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 with such decisions.

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. Okay, perfect. 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. So 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. And we picked an area that we really liked, and this was Fargate. And this was then why we started writing Rapid Docker on AWS. And 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, Node.js, Python application

as far as possible. And so we wrote a small book. It's only 120 pages. So but it's to the point, it's only the relevant parts are in it. And we also build 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 a deployment pipeline. So everything bundled together, of course, monitoring is included with CloudWatch as well. And we bundle that together so that as many people as possible can easily deploy their workloads on Fargate. So that is the intention of the book. 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 and on some level just at a cursory glance, oh it's a sales pitch for service X. And 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 this is a, 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. And until people try something with it, it's very easy to overlook. 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 have 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 running the containers and an RDS Aurora database,

we really think that this is a modern architecture to build on AWS that just focuses on simplicity. And 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. And I think that's what a lot of people, a lot of developers actually are looking for. And 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 spend 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? So that is part of the book as well. You bring up a couple of other interesting things that I'd largely forgotten about. First,

whatever 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.cloudanaut.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 grant access to do everything. And I'm

sure I'll remember to go back and fix it later. Yeah. So I think we built the IAM.cloud on our 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 resourcing conditions that are available. 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. And 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 even-handed, and 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 to Global Accelerator was simply, I'm not sure what it does, so I imagine 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. So 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. And one service that was announced at reInvent 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. And finally, I found some time to actually look at it a little deeper. And the thing is, the promise of Global Accelerator, or actually two promises. One promise is Global Accelerator will reduce the latency, the network latency from your clients to your AWS infrastructure. And 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. And so I did some testing. And so the thing with multi-region deployments and routine 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, yeah, we're making it faster, so we reduce latency. This was interesting because I actually wanted to measure what that means in reality. And 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 yeah, another solution that is useful

when you try to reduce latency and yeah, use that to dive a little bit deeper into the latency reductions that can be achieved with Global Accelerator. 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? So 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. And as we all know, each and every millisecond that you can reduce typically helps in e-commerce, in gaming, in finance, and so on. So it's probably valuable for a lot of scenarios. What other services have you been seeing that you think don't have enough of a light being shown upon them? And again, we are recording this before reInvent. So let's look back in time over, I guess, the previous year before reInvent 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? So actually today I played around with Amazon Connect. So the contact center solution, and I was really impressed about this service. So I didn't know that this existed, but I never used it before.

And today I just had a small use case to try it out and to build a small project with it. And 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're creating a contact center within minutes and it's very easy to connect the 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. So the service that you can use to query data, unstructured data, actually, that is stored on F3 with a SQL-like query language. That is a fantastic point where the idea of having a SQL query language is, well, 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. Yeah, absolutely. So I think Athena combines that, so the SQL engine, and also the possibility to just store the data on a three, which is very convenient and very easy. Also possibly cheap to do. And 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 the query you pay for the processed amount of data. So that is very very handy. So I'm using it for example for the latency benchmark and 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 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 three and then use Athena to get some insights out of that. 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've played with has been Redshift. And that apparently runs on burning piles of money because

you need a lot of those to wind up parallelizing the queries appropriately. Yeah, absolutely. So Athena and then another interesting service that relates to that is QuickSight. So I know you always say they don't probably have any customers, but they have at least one. I wish it were better than it is because I am burning a fortune on Tableau licensing instead. Yeah. So 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 here 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 only three 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. 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.

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, jerk face. Here's exactly what we're doing. Tell me 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. Yeah, that sounds great. So I have something to add to that list as well.

So 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. And 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? Yeah, very good question. So it comes down to maybe three main topics. So it's technical coaching.

So we coach individuals or teams to get started with AWS or with a specific part of AWS, for example, containers on AWS or serverless. So that is one part that we do. We call it technical coaching. And the second thing we do is infrastructure bootstrapping. So we mentioned already that we have some CloudFormation templates open-sourced and we use them to spin up infrastructures very quickly. And usually we can get maybe 80 to 90% of the infrastructure that a project needs up and running with our base templates. And 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. So that is what we call infrastructure bootstrapping. This is typically something we do for something between one or four weeks. And at the end, we hand over the infrastructure, the documentation,

and train the team that is then in the future and taking care of that infrastructure. So that is the second part. And the third thing we do is we also, so 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. So that is the third thing that we typically do in our consulting business. So if people want to learn more about the various things you do, where can they find you? So I think the best place to go is cloudonout.io. So this is our blog, and it actually links to everything we do. So you can find our podcast 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 where you find everything that we do, cloudonaut.io. And 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. Thanks for having me. It was a great pleasure.

Andreas Wittig, founder, entrepreneur, author, Gadfly, etc. at cloudonaut.io and Wittigs. 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. 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 humble pod production stay humble