Loading summary
Transcript12 lines
- [00:00]
A
What if we told you that AWS has its own version of Killed by Google? It's actually an AWS official page that lists which products are being retired, phased out or closed to new customers. And if you actively use AWS and you use a broad range of services, this is a page you should probably bookmark. Today we're talking about the AWS Product Lifecycle, what it is, what you'll find there, and how it can help you to avoid nasty surprises. We'll also look at some products that are already on their way out and maybe even some more predictions on what could be next. Welcome to AWS Bytes. I'm Owen. I'm here again with Luciano. Let's jump in. This episode is brought to you by four Theorem. Stay tuned for more about that at the end of the show. So what is the AWS Product Lifecycle page? Well, AWS quietly launched this page, which is a bit like a changelog for AWS product retirements. The link will be in the show notes. It was only announced in May of this year and there you'll find products that are being deprecated, services closed to new customers, products entering long term support and explicit end of life dates. Now, unlike Killed by Google, this isn't a rage fueled graveyard. It's an attempt to be a transparent and structured overview. It comes from AWS and we're honestly happy that they made this official. So it gives us developers, teams, enterprises, a clear roadmap to avoid surprises, sunsets and to be able to plan migrations with some time to spare. So why do you think they might be doing it?
- [01:36]
B
Duchenne yeah, it's interesting because I think one of the things that I always loved about AWS is that they used to be famous for keeping services running pretty much forever no matter what. And one example is simpledb that is still available if I'm not mistaken. Although I think at this point everyone is using replacements like DynamoDB, right? And yeah, I think this used to be a thing that everyone would be saying in the last few years about aws, like they're never going to deprecate any service, so super stable and everything. But of course we know that this is not going to be sustainable forever and AWS at some point realized that as well. And there was a moment where AWS started to deprecate a few services and there was a little bit of backlash. So yeah. Why do you think that AWS has been cleaning up more and more lately?
- [02:29]
A
Well, we can only guess, but some of the reasons might be it had to happen Sometime you can't just keep adding services and support them without having enormous maintenance costs. On the AWS side, they also laid off quite a few staff last year, and you can imagine that this means you have to focus on certain product priorities and cutting back on others. I also wonder if AI and Genai in particular has caused a big focus shift. We know that some so many announcements and so much marketing from AWS over the past year or so has been around AI Q bedrock, so this sudden shift must mean that some things have to hit the scrap heap to make room. Should we talk a bit about what's on this product Lifecycle page? Maybe a lot of people might be surprised to hear what's on there and what's already on the chopping block.
- [03:13]
B
Yes. So this is at the time of the recording. Of course we expect this page to evolve over time, so always keep an eye. And if we are listening right now, as we just published this episode, hopefully this is still going to be pretty relevant. So the important thing I think is that there are different categories. So the first one is Services closing access to new customers. So the idea is that if you're using a service already today, that service is not going to go away for you immediately. But it's more if somebody's creating a new account, that service is not going to be available in that new account. So that is of course a strategy that AWS puts in place to give a existing customers time to migrate out, while they don't want of course to overload themselves with new customers as they are trying to phase out a product. And just to give you one example of what's there right now there is Amazon Timestream for live analytics and if you look at the official docs, it's interesting that they are already recommending to use Amazon timestamp for InfluxDB as an alternative. So there is already some kind of a migration plan. I'm not sure if there are additional tutorials or guides from aws, but I wouldn't be surprised if you search for them. Maybe you'll find something like that. But this is just to give you an example of what might be appearing in this section. And yeah, if you're using timestream, I think timestream is still available. It's more this particular variation of timestream is gonna go away, so just be aware if you are a user of timestream. I'm personally not an expert in timestream, so hopefully I'm not saying anything misleading. Now another category is is Services Announcing End of support and this is the
- [04:48]
C
one That I think right now has
- [04:50]
B
the biggest list of products and there are services that are officially heading for retirement. So AWS is starting to provide migration paths and timelines and this is where you really want to pay attention because of course, the sooner you're going to catch something there, the more prepared you can be to figure out what is a strategy to move out from those services if you're using that. Now, to give you an example, the first one worth mentioning is Amazon Pinpoint. Just because I can say we told you, of course I'm joking. We made an episode, episode 98, I think it was almost two years ago at this point, where we were discussing some of the drastic quota changes that Amazon put in place for Pinpoint and we got a little bit suspicious that maybe as a service it wasn't getting a lot of traction or maybe it was too difficult to maintain at that scale. So we just assumed that it eventually might be phased out. And so it happens. Maybe we were right, just like it. But yes, just this is an example of the kind of products you can see here.
- [05:48]
C
Other examples are AWS iq, which is the marketplace for freelancers where effectively, if you have AWS skills, you can look for customers. And we expect that, yeah, since this is going for retirement, AWS doesn't want to maintain that marketplace themselves. Maybe there will be other alternatives that are not strictly officially promoted by AWS. Then we have two IoT services, AWS IoT analytics and IoT events. And we also have AWS Panorama, which is if you're doing computer visions and you want to do it on premise, that's the kind of service that AWS used to provide. Now, again, these services are not gone yet, but we can expect that they will eventually go. So start to prepare yourself if you're using them, start to look at the documentation, start to see what AWS suggests as a migration path and just be aware about the timelines. Now the next one is Services and Features reaching end of support. So these ones are services that are already gone. So the end of life has been reached. And if you try to use them now, you will basically hit a wall. And two elements, two services are there right now and there is AWS private 5G and AWS datasync discovery. Now there is also a generic note that says if you are affected or unsure, reach out to AWS support or check the specific service document. So just be aware that, yeah, this seems like a little bit of a vague suggestion, but I honestly suspect that this is just because this section is probably something that AWS is still working on and they will probably improve it as they go.
- [07:15]
A
There are actually services that are already end of life but predate this product Lifecycle page and they're not there yet. One example is opsworks, which was I think reasonably popular, Managed Chef and Puppet solution and that has been end of life since May 24th. And other examples include QIIME, CodeCommunMit, Cloud9 and QLDB or Quantum LedgerDB. A lot of those were not quite announced, but they were deprecated or sunset at around the same time. And there was quite a bit of backlash from the community on the lack of communication when these deprecations happened, especially with CodeCommunmit, because that's something people really rely on if they're using it. And also you had things like Control Tower solutions being based heavily on CodeCommunMit, so it was not handled very well. Maybe this product lifecycle page is AWS's way of trying to address those communication issues and do things a bit better for the future. Now, with all that said, let's get into crystal ball time and try and think of what other services might be deprecated in the future. Now, big disclaimer. We don't have any insider knowledge and if we did, we wouldn't use that here or disclose it here. So this is just a guessing game and a random chat at the bar between friends. So here are a few guesses. There's so many different ways to run a container on aws. You can imagine that at some point they might like to consolidate. And we talked recently about App runner in episode 143. Go to awsbytes.com 143 and I have to say we've really liked it in principle. The only problem is that there's still a lot of overlap with other services. Bit of Fargate, a bit of Beanstalk, Elastic Beanstalk. It always felt like App Runner was going to well, it was at least a candidate to replace Elastic Beanstalk for some use cases, but in reality we haven't seen that much development on it. So is one of those two going to be sunsetted eventually? If yes, which one? Is there going to be some sort of consolidation of container services under an umbrella? Maybe the Fargate umbrella would be nice just to make it easier for people to pick and choose those services and to switch between them. And I guess when it comes to the actual deprecation of them, customer adoption is probably going to dictate that.
- [09:22]
B
Yeah, if you want my guess, one of the areas where I've always struggled the most is API Gateway and especially version one versus Version two. And I think that's very common for full stack developers, Web developers using AWS, they build lots of APIs, and it's always a little bit of a struggle to figure out which one do I use. And we spoke about API Gateway, the different versions and other ways to create HTTP endpoints basically on AWS in a serverless fashion and back in episode 74. So go to awsbytes.com 74 if you want to get more details on all the options that you have available. But my point is that basically these two versions of API Gateway are effectively competing for features. And for sure, inside AWS there is a little bit of a waste of development energies, maintenance, management and everything else, because effectively they have to mandate two things that are trying to do the same thing, maybe in slightly different ways, maybe more optimized on different areas, but effectively from the customer perspective, it's very difficult to pick one over another. So that's probably an area where AWS will eventually have to make a choice even to just simplify for the customers, not just for themselves. But the interesting guess is like, which one is going to go right? Because you might think that v2 is the newer one. It's also maybe a little bit cheaper, a little bit faster based on some benchmarks. So it's easy to expect that V2 is the one that's going to stay and V1 is going to be phased out. But in reality it's fair to say that V1 still has a lot more features and integrations with other AWS services. So the choice I don't think is that obvious. So what do you think? Do you think V1 is going to win or V2 is going to win? Let us know in the comments. But if you want to know our guess, I think V2 is the one that is going to lose, not stay, just because our guess is based on recent announcements. And so it happens that there were more recent announcements for V1. Specifically. The last one was an API Gateway V1 announcement called Dynamic Routing. We'll have the link in the show notes if you're curious. Now, Owen, do you have any other guess?
- [11:29]
A
Maybe they'll just add V3 and we'll have.
- [11:31]
B
Oh, that might be. Yeah, the one that solves all the problems.
- [11:37]
A
All right, so yeah, other honorable mentions that we think might hit the chopping block. We've got simple workflow service. I think there's still people using this, but largely it's been superseded by step functions, the Chime SDK is something that I don't know if it got a lot of adoption. We've definitely used it on a previous project and it worked very well. Unfortunately it never had cloudformation support, which is a bad bad smell. And qiime itself is already end of life. So you have to wonder about qiime SDK now maybe a controversial one Serverless application repository or sar, only because we haven't seen too much adoption now we like the idea and we use it and we publish to the services application repository. It's also kind of a hard one to deprecate if a significant number of people depend on it, so it's hard to see it being completely deprecated, but it would be great to see more adoption. Another victim might be Neptune. The graph database that AWS has. We haven't heard that many people using it, and the people we have heard of using it give us this kind of non scientific conclusion that most people prefer to host Neo4J or something else when they need a graph database. So maybe that's another candidate in the whole Alexa Lex space, especially given so much upheaval and development around Gen AI, we can imagine those services being replaced by Bedrock or Q or something under that umbrella. They've already announced a new Alexa replacement or X premium version called Alexa, which seems to be a paid solution and it's all based on Genai, so I guess all these services are going to have to improve anyway. The kind of Pre LLM voice assistants tend to be much worse as a user experience anyway, so maybe Alexa is going to get the boot and in the areas of DevOps and containers. Proton, which is something that was announced a couple of years ago. A lot of people were curious about it, but I just haven't seen that much adoption in practice. It was intended to make the whole infrastructure versus Development teams deployment pipelines for organizations that had separate ops and dev pillars was intended to make that much easier, but I just haven't heard that much. It's been pretty much tumbleweed since so maybe Proton is getting the axe and then one we did put a lot of effort into an episode on, I have to say, so it would be a shame to see it go Is the copilot clique in AWS now this is not to be confused with GitHub Copilot and Microsoft's Copilot Everything, but we also haven't seen too much about the Copilot cli and it was, you know, convenient CLI for deploying containers on aws and we did a whole live coding episode that turned out to be way much more work than we anticipated, so we still got some battle scars from that, but it was still a learning experience. So that's our list. Now those are remember, just our guesses. There's nothing there that you should necessarily bet on, but let us know what you think. Hopefully. At least now you know where to look when AWS decides to sunset a service. And maybe we helped you to spot a few warning signs before they become headaches. Just because we were right about Pinpoint doesn't mean we're right about the rest. We're not trying to play AWS doom clock here, but we just want to make sure we're all informed, especially if you're making long term architecture decisions. And at least this Product Lifecycle page is a good tool to keep in your back pocket. Let us know what you think and give us a share of your guesses in the comments. Finally, big shout out to fourth E for powering yet another episode of AWS Bytes at four Theorem. We believe the cloud should be simple, scalable and cost effective, and we help teams just to do that. We're Whether you're diving into containers, stepping into event driven architectures, or scaling up a global SaaS platform on AWS, even if you're trying to keep cloud spend under control, our team has your back. So visit fourtheorem.com to see how we can help you to build faster, better, and with more confidence using aws. Thanks very much and we'll catch you in the next episode.