In this episode we are talking about what we would like to see at AWS re:Invent.
What would you like to see?
Serverless Services
An increase to the enhancement and evolution of service development capabilities and the ecosystem in general. So more serverless services coming online for items that aren't serverless and iterating to be more serverless. There's a bunch of things that people are almost afraid of like observability, deployment patterns and some of the frameworks.
API Gateways
In service development, Private API gateways are interesting, but they could be more developer friendly, in terms of setting up, naming and managing. We are seeing more enhancements around eventing capability like SNS filtering, SQS and X ray. These are things that make the serverless experience more rich and all encompassing.
Developer Enablement
You need to think about developer enablement and time to value. Can you get a developer up and running with a productive IDE in the cloud? And can they start delivering value rapidly? We're seeing steps around Cloud IDE starting to emerge. I want to see what AWS does around their Cloud9 offering.
Well Architected
Over the last year, we've seen good announcements on well architected capabilities, systems and services. I want to see a continued evolution of that. And more well architected thinking and characteristics baked into everything. All the way from developer advocates to patterns and code samples. Some of the basic primitives are moving up a level to something more like a pattern.
It's about fast feedback and dare I say the value flywheel. Can the pipeline's tell us how well architected the chains that we made are. And can our IDE tell us how well architected we are? Stitching that together in a compelling way with fast feedback for the developers would raise the bar on what developers deliver into production.
That's effectively platform heuristics. I remember back in the IBM mainframe days, it was a mature platform. And you knew it so well, that they started to bake in heuristics. When you start to analyse your code there would be a heuristics to say this might be wrong. Here's what you need to do to fix it.
We're starting to see some of these elements emerge already with Security Hub, Reliability Hub and Fault Injection Simulator. It's about stitching those together like factory mode for workloads in your accounts. Tell me we're not well architected, and tell me how to fix it.
Sustainability
More fine grained analysis of carbon scores would be useful when teams are designing and building their workloads. And getting faster feedback on a particular service and how much it is going to cost you in carbon.
What's the wacky stuff you would like to see?
I'd love to see work on APA management and API gateways. Factory mode for your accounts. How well architected are you would be really good. Instead of us having to do the reviews and do it manually. The gateways are due an uplift or enhancement. What about documentation? And how you consume information about services. We are seeing an explosion of services on the console. Is there going to be a cut down console just for your layer? Cost is always a big one. FinOps is a massive growth area with a lot of good tools out in the mar
Hi folks! Welcome to the next edition of Serverless Craic with Dave Anderson, Author and Contributor at The Serverless Edge and Technical Fellow with Bazaarvoice.
Mark McCann:
Hi everyone. Mark McCann, Architect at Globalisation Partners. And Author and Contributor at The Serverless Edge.
Michael O'Reilly:
Michael O'Reilly, Architect with Globalisation Partners and Contributor at The Serverless Edge.
Dave Anderson:
I know it's World Cup fever. But it's also AWS
re:
Invent fever. AWS are having their annual conference Invent. I will be heading over.
Mark McCann:
We'll do 'watching the videos'. You'll do more
Dave Anderson:
It's usually on the week after Thanksgiving. walking. Traditionally, the Monday is pretty open. The CEO, Adam Selipsky will do a keynote on Tuesday. Swami Sivasubramanian will do a keynote on Wednesday on ML. And Werner will do a keynote on Thursday. That's the engineering/techie keynote. They will have loads of announcements at those three keynotes. And then there are loads of breakout talks. There are approximately 30 to 40,000 people going. We figured we would chat about what we would like to see at AWS re:Invent? The AWS internal
teams work towards re:
Invent to make their big announcements. Sometimes they have annoucements beforehand. But the big announcements will be on stage. What would you like to see?
Mark McCann:
For our context, I would like an increase to the enhancement and evolution of service development capabilities and the ecosystem in general. So more serverless services coming online for items that aren't serverless and iterating to be more serverless. There is still a high cognitive burden for teams adopting serverless. So remove some barriers to that adoption to make easier for teams and developers to get started. We're seeing a lot of this already. Developer advocates are doing a great job educating people with Serverless Land, patterns and workflows. There is always something that AWS pull out of the hat like some big new serverless thing. It will be good to see what that is.
Dave Anderson:
It's the serverless developer environment and helping serverless developers. There's a bunch of things that people are almost afraid of like observability, deployment patterns and some of the frameworks. So make those a
Michael O'Reilly:
They have invested into Cloud Watch with bit easier. the run and performance. It looks more like a product that you would leverage. In service development, Private API gateways are interesting, but they could be more developer friendly, in terms of setting up, naming and managing. So it will be interesting to see what they do around the whole API gateway service.
Dave Anderson:
The edge around the environment needs to be tightened up. I don't think they have nailed the data options
Mark McCann:
We are seeing more enhancements around eventing yet. capability like SNS filtering, SQS and X ray. These are things that make the serverless experience more rich and all
Dave Anderson:
What do you call that feature? Is it the chaining encompassing. of traces through the different tools? That leads on to developer enablement. It's one thing to help people build better in serverless. But it's another thing to help with general developer enablement. One trend from AWS in the last couple of years is Guru like Code Guru or DevOps Guru. GtHub were doing it with GitHub pilot. I'm not sure if I buy that. There was a tweet a few days ago, that said that AI will change code and because AI will write all the code for you. With the code is a liability mindset, that's not the approach you want
Michael O'Reilly:
There are legal issues around how they to take. train those models, like copyright infringement.
Dave Anderson:
The hardest thing when you are building something, is not typing in the code.
Mark McCann:
You need to think about developer enablement and time to value. Can you get a developer up and running with a productive IDE in the cloud? And can they start delivering value rapidly? We're seeing steps around Cloud IDE starting to emerge. I want to see what AWS does around their Cloud9 offering. So that you can go from idea to something deployed and running within minutes. The building blocks are starting to be put in place. I want to see what's next.
Dave Anderson:
I am quite visual when I think about these things. The visualisation of some of those serverless and cloud systems is problematic. You will remember, many years ago I was always going on about drawing proper diagrams! It feels like we've evolved from the architecture diagram as a static thing, but I don't think it's been replaced well.
Mark McCann:
Beyond developer enablement, once developers are up and runnnig we are big advocates of the well Do you think we need more tooling to support well architected framework. And we have been banging the drum for teams delivering well architected solutions. Over the last year, we've seen good announcements on well architected capabilities, systems and services coming online within AWS. I want to see a continued evolution of that. And more well architected thinking and characteristics baked into everything AWS are doing. All the way from developer advocates to patterns and code samples. We should be asking if that is a well architected sample or solution that they're describing in their blog post or Serverless Land patterns etc. And that it has answered the question of could you take it to the higher environment? Could you take it to production. There's a tricky line to walk there. Because you don't want to overburden people if they're only getting started with some of these things. But I think we'll see more of that. architected? Or well architected integrated more into deployment and run phases of Cloud.
Dave Anderson:
I think there's two parts to it. Well architected needs to be better known. A lot of people still don't know what well architected means. There is still work to do to get people to understand what well architected is and what it isn't. And have it present in the tools and not a separate thing that you need to go and do. It should just be there in your job. And there's a second thing, which is the idea of primitives, which is a bit left field. Some of the basic primitives are moving up a level to something more like a pattern. Developer advocates are great at this with Serverless Land. It would be great to see some consistency in those higher level primitives. It is maybe what Jeremy Daly is doing with his new company AMPT with the Infrastructure FROM Code. There are some ideas around this. I'd love to see Gregor Hohpe's new enterprise language or pattern language.
Mark McCann:
It's about fast feedback and dare I say the value flywheel. Can we get more feedback faster on our well architected status? Can you tell us how well architected our workloads are in our account? Or can the pipeline's tell us how well architected the chains that we made are. And can our IDE tell us how well architected we are? Stitching that together in a compelling way with fast feedback for the developers would raise the bar on what developers deliver into production. Hopefully it will start to come out at re:Invent this week.
Dave Anderson:
That's effectively platform heuristics. I remember back in the IBM mainframe days, it was a mature platform. And you knew it so well, that they started to bake in heuristics. When you start to analyse your code there would be a heuristics to say this might be wrong. Here's what you need to do to fix it. And then you get to a point where it says, I've just fixed this for you. Is that okay?
Mark McCann:
We're starting to see some of these elements emerge already with Security Hub, Reliability Hub and Fault Injection Simulator. It's about stictching those together like factory mode for workloads in your accounts. Tell me we're not well architected, and tell me how to fix it. That's the
Michael O'Reilly:
It's a philosophy. Well architected is guidance you want to see. a set of opinions. But there could be more done to facilitate adoption of those opinions. Or test that we adhere of are configured for that particular thing. I like that comparison to heuristics and a set of rules. We do apply tools to validate Cloud Formation or YAMYLs. There is a demand.
Dave Anderson:
Well architected is a set of opinions. But they are based on the experience of talented architects working with a lot of customers. There's probably an extension to that. As we enable developers I'm seeing good industry examples from new tools that have been launched. In other words here's a new feature and here's how it applies to your particular industry. It's less abstract. I'd like to see more of that as
Mark McCann:
It reduces cognitive burden. Industry well. specific examples remove the fear factor of applying the tool to the insurance industry, for example. There's an example that you can point to like SNS filtering and auto insurance or property insurance or filtering messages and an SNS topic. It removes barriers to adoption, when you see an industry specific example tailored to your particular domain.
Dave Anderson:
Or you've just spent the last four years building something and they say'ta da, here you go'. Sustainability is a topic close to our hearts. I haven't heard much about it this last while. Adrian Cockcroft has moved on from AWS. He still has lots of really good content, if you follow him on Twitter. But it would be nice to see them continuing that journey, which I assume they will. There will probably be more maturity in how they measure, present and analyse your workloads.
Mark McCann:
More fine grained analysis of carbon scores will be useful when teams are designing and building their workloads. And getting faster feedback on a particular service and how much it is going to cost you in carbon. We're starting to do this a lot with teams when we're doing well architected reviews and the SCORPS process. Cost is a factor, but we're introducing carbon score as a factor. More granular tools would allow us have a better conversation. So hopefully there's something coming.
Michael O'Reilly:
Even moving some of their data centres to be greener.
Dave Anderson:
What's the wacky stuff you would like to see? I'd love to see work on APA management and API gateways. I think there's a whole bunch of work that they could do there. I don't know what it is but it just feels like there's more to do there.
Mark McCann:
Factory mode for your accounts. How well architected are you would be really good. Instead of us having to do the reviews and do it manually. I think we are a while off that, but we could be surprised.
Michael O'Reilly:
The gateways are due an uplift or enhancement. What about documentation? And how you consume information about services. We've got lots of patterns and advocacy. And there's lots more content coming
Mark McCann:
We are seeing an explosion of services on the out. console. Is there going to be a cut down version just for your layer? There's a lot of noise to signal ratio there that you don't need to deal with.
Dave Anderson:
Just give me a service console.
Mark McCann:
Just give me the service console. Ditch everything else.
Dave Anderson:
Cost is always a big one. FinOps is a massive growth area with a lot of good tools out in the market.
Michael O'Reilly:
The only other one I can think about is Identity. It will be interesting to see if anything comes out with Cognito.
Mark McCann:
Cross region and multi region, Cognito had issues. If they solved some of those things it could be more compelling.
Dave Anderson:
That's the craic. I'll be walking a lot this week in Las Vegas.
Mark McCann:
And you are bringing The Value Flywheel Effect books?
Dave Anderson:
Yes, I'll bring The Value Flywheel Effect books! Visit our blog on TheServerlessEdge.com. And follow us on Twitter@ServerlessEdge and subscribe to the Serverless Craic YouTube channel. Thanks very much. Bye, everyone.