Monitoring platform for keeping systems up and running at all times.
Full stack visibility across the entire stack.
Detect and resolve any incident in record time.
Conform to industry best practices.
Serverless adoption has become a popular topic of discussion and the methodology seems to be gaining more and more traction every week because of its massive business benefits.
A growing community of enthusiasts has emerged and we wanted to find out what these serverless evangelists predict for the future – when will serverless computing become the norm, who are the biggest winners/losers and how to get more people to try it out?
Full Stack JavaScript Developer & Entrepreneur. Developer @Serverless
Yes. Serverless computing will become the de-facto way folks will build apps in the future. At Serverless Inc., we are already seeing large enterprise companies running massive workloads through tiny lambda functions.
AWS always does a great job at highlighting companies who are using lambda & other serverless offerings at their Re:invent state of the serverless union talk. I recommend watching it.
The devs using it.
Having to not worry about scaling, load balancing, security patches etc. make serverless a fantastic way to build robust applications with minimal DevOps.
Cost in the typical cost savings from a pay per execution pricing model of FAAS providers and you got a no-brainer.
The container world & tooling around containers certainly will start seeing the effects as serverless tech gains more prominence.
But that being said, there are a number of serverless FAAS providers that run on top of Docker/Kubernetes. There are also certain workloads that don’t make sense in a FAAS world and containers + container orchestration tools, I believe, will be around for a long while yet.
We will start to see dramatic reductions in “cold start” times and the developer tooling around many FAAS providers will become much more solid.
I think the easiest way to get people started with serverless is to have them identify something non-mission-critical to port into a FAAS provider of their choice.
Once they see how easy it is, they can often take that POC and expand it into many facets of their organization.
Approaching upper management with a proposal for a big bang rewrite on any tech is typically shut down within seconds. It’s much more easier to start small, see the benefits from a smaller project, and expand serverless tech into other areas of the business.
If you’re interested in getting a baseline in how serverless works with AWS lambda, I have an open source step by step workshop for people to check out.
Serverless to me is an auto-scaling, event-driven architecture, where you never pay for idle functions, the system is implicitly fault-tolerant and functions are the unit of development & deployment.
There is also this notion of offloading things that aren’t your business’s core competencies to third-party service. So you can focus on delivering value to your users.
In my personal opinion, it gives developers a lot of power to ship more code with less of the lower level maintenance/up-keep/scaling burdens of yesteryear.
Author of “Learning Concurrency with Python”; Pythonista; Web Hacker; Owner of Tutorialedge.com ; Software Architect @JPMorgan.
Serverless computing is going to revolutionize the way we build and deploy applications. The advantage of being able to deploy an endpoint or a series of endpoints that are incredibly resilient, as well as hugely scalable is massive.
Everyone.
People who are unwilling to consider the use of serverless for their own applications.
We are going to see a huge number of new startups popping up and leveraging serverless for their own gain. These startups will be able to compete with large, existing enterprises from the word go.
Serverless Framework is making the deployment and management of serverless functions an absolute breeze. You can check out my article on how to manage your serverless functions here!
Support me by subscribing to my Youtube channel.
Founder @ServerlessOpsIO / 1x engineer.
I believe it will become the norm but I’ll skip giving a when.
Why do I think it’ll become the norm? It’s watching the Kubernetes community develop serverless frameworks. It’s watching Red Hat focus resources on Apache OpenWhisk. The infrastructure and platform management communities aren’t stopping at containers.
The question as I saw it a year ago was, “Do you adopt containers or do you adopt serverless?” It was a question about what technology to adopt and competing technical views. Seeing the serverless progress in the infrastructure management space makes me realize the future question will be, “Do you build your cloud platform or use someone else’s?” Do you build or buy?… Which is just the same old basic question we’ve always been asking ourselves.
People who make the connection between technical effort not being an end goal, but as a means of producing value.
Serverless, particularly public cloud serverless, lets you focus more on the code and less on the infrastructure. That doesn’t mean you let code fill that new cognitive focus space. Move up the value chain and start focusing on whether your code is a success. And by success, that means, “Did your code solve the problem it was intended to solve?”
Let’s assume you’ve built something for a group of users to save time. Once your code is shipped, are users using it? Do users actually save time? And most of all, are your users actually happy?
Good companies get this connection between technical effort and producing value.
People and organizations who cannot adequately connect technical effort with value will lose the most.
If you’re a company you’ll be outpaced by the competitor that produces better value quicker.
If you’re an engineer you’re going to be tasked with explaining and justifying technical decisions in business terms and owning its success or failure.
We’ll agree that serverless does in fact use servers and we’ll move onto bigger and more important discussions. I expect to be wrong in this prediction.
There’s a definite knowledge gap about serverless architecture. Containerization is just a new way to manage the same services we’ve been building for many years.
Serverless is different. Complex event-driven architecture is new for many of us. Bundling code and architecture as one is also new for many of us.
Principal Engineer at DAZN. International speaker, blogger, instructor of Production-Ready Serverless and co-author of F# Deep Dives.
Yes, within 7 years.
Consumers.
More people sharing real-world experiences (both gains and pains) of their own adoption.
Software engineer @bookvar_co. Coding educator @ACADEMY387. Author @PacktPub. Local leader @freeCodeCamp Sarajevo.
In some context, it will! But not every problem you face as a software engineer will be solvable by a single tool. Dedicated servers will still have their concrete use cases. However, these use cases will decline more and more in the coming few years, in turn giving serverless computing and tooling place to thrive, as I believe it deserves. Not only because of simplicity, but also because of the huge difference in price giving startups a fair chance to compete on the market.
Developers! Sadly, every day I see a decline in operations-oriented engineers. I can understand why, simply because it’s incredibly hard.
Serverless architectures give devs the power to run and scale apps across the cloud and ensure maximum uptime without losing any sleep. The close second winner would be companies getting the competitive edge by not spending too much time on DevOps… unless they’re super cool and choose to use Kubeless. 🙂
I can’t see a real loser in this hype-train we call serverless architecture. All major cloud providers are following the trends and offer awesome services. We, Devs and DevOps engineers are high-demand merchandise, so I don’t see any of us facing issues finding jobs in new fields.
More than 70% of all newly founded startups will use serverless architecture in some form or another in their product.
Proper education! We need to make sure content is readily available. Educating the masses has always been an issue throughout history. We need to act smart and give devs a coherent pipeline through which to learn about the core principles of serverless architecture and what it really means to use serverless tech.
Step one would be to explain why it is called serverless to all the internet trolls spewing hate on social media that it still uses servers. I think we all know that already. 🙂
Step two would be to get the major players in the field to work together towards a common goal through organizing workshops, courses, and events.
Here’s an idea, just as DigitalOcean and GitHub have been collaborating to create Hacktoberfest as a way to get the community to contribute to Open Source, why not do something similar with the goal to educate people about serverless!?
Yes! Don’t stick to your beliefs like they’re religious dogmas. If you think serverless is bad, and heavily rely on dedicated servers, it’s totally fine. But, feel free to consider both upsides and downsides.
The same goes for serverless fanatics. If it makes sense to use a server, use it, don’t be hard-headed and push your will to use serverless to the extreme.
Trends in tech exist because they make sense. Using serverless makes perfect sense in a huge variety of use cases, while in some it doesn’t. The availability of learning this, again, needs to be open to the masses. It’s our job to make it happen.
Works @goserverless. Ruby, Golang, API Aficionado, Docker, Mesosphere, Serverless. BSA ASM. Photographer. Entrepreneur @webintellix .
Serverless computing is the most exciting technology in cloud computing. Yes, it will become the norm and the only way to realize maximum business value, and drive down operational costs.
We have seen the cloud evolve since 2009, but serverless computing is how the cloud should have been in the first place.
While cloud computing enabled us to move workloads off our data centers, share compute, storage, networking resources and make it cost-effective, it just shifted the maintenance overhead to the cloud.
Serverless computing takes away the overhead of DevOps teams from managing servers to focusing on operations that drive business value. It empowers developers to focus on delivering functionality that enhances business outcomes rather than worrying about managing infrastructure, deployments, and scaling.
The enterprises will benefit from the pay-per-execution pricing model and the large ecosystem of serverless services provided by multiple cloud and SaaS providers.
In my opinion, everyone wins – individual developers, small-medium businesses, and large enterprises alike.
The ones that are already on the cloud and run existing workloads on cloud providers like AWS, Azure, and Google cloud have an upper hand. They are already past the “Why should I move to the cloud?” hump, and more aligned to take the next leap to going serverless.
It is not too late for the ones that are still not on the cloud – they should adopt the “Serverless First” mantra, and evaluate incorporating serverless technologies starting at the periphery of their systems.
The ones who don’t want to embrace the change, and not giving a serious look at the benefits that serverless computing offers. They need to start evaluating and identifying areas that can be re-architected.
It does not have to be an all-or-nothing deal. Businesses can start with non-critical systems to get started, and then set a longer adoption plan in motion.
Rise of startups focusing on building tooling around managing functions, team collaboration, observability, monitoring, distributed tracing, debugging, security, logging, and auditing.
Businesses taking a hard look at multi-cloud adoption freeing them from vendor lock-ins and utilizing services across multiple providers based on feature sets, quality and cost-effectiveness.
We need to talk and write more about it.
Businesses and developers alike should share real use cases and publish case studies for others to learn from.
The influencers and early adopters need to share code, examples, advice, learnings and their experiences.
We need to unite as a community beyond our own products, irrespective of cloud platforms, and evangelize the business values & benefits of serverless architectures to the masses.
Head of Development at @acloudguru, Serverless enthusiast, writer, cyclist, terrible gardener.
Yes. Serverless is based on the philosophy of focusing on delivering value and avoiding undifferentiated heavy lifting. There is a strong business case for this philosophy and as a result, I see that helping drive adoption to the point where it will be the norm. But, this will take a long time.
Many companies are still unsure about the cloud or serverless due to a lack of understanding. Advocacy and education will play key roles in driving Serverless to become the norm.
There are many winners, businesses, developers, and vendors. Who wins the most is difficult to say. I’d say businesses that leverage serverless as a competitive advantage win the most from the adoption of the technology.
Vendors that deliver technology or services for elements lower down the stack like servers and containers. For example, Digital Ocean and Docker.
Serverless will become more normalized throughout the community. The big releases from AWS will be more focused on Serverless ML/AI services than data or messaging services.
Promote it by telling authentic stories to meetup groups and friends in the IT community.
I should, of course, say, go watch one of our courses too!
DevRel for Auth0 Extend, Star Wars nerd, Web/Serverless hacker, lover of good beer and good books. Oh, and cats.
I think there are a few ways to look at this question. One is – when will it become less the “hot new thing” and “just another option”. I think that’s becoming reality now. Serverless still has an incredible amount of hype around it, but in general, it feels like it is becoming mainstream and less bleeding edge. That’s a great thing.
The second way of looking at the question is in regards to serverless becoming the default for application development. I think serverless has some incredible benefits over traditional server-based architectures. While I don’t think serverless makes sense everywhere, I definitely see it as the option developers should check first.
Developers!
PaaS offerings. While I definitely do not see them going away, I definitely see using those options less. Of course, companies that offer both will have their bases covered.
Serverless deployment will be the default, the assumed route.
Education, advocacy, just spreading the word. As a developer advocate myself, it is my job to let people know not only the basics but to also inspire them.
The best serverless demos make use of cats. Anything else is simply wrong.
We want to thank all the people who took the time to answer our questions and shared their thoughts!
If you have questions or topics in mind that we should cover next, let us know in the comments section. And, of course, don’t forget to check out Dashbird for serverless monitoring and debugging!
Today we are announcing a new, updated pricing model and the end of free tier for Dashbird.
In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.
In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.
Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.
Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.
Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.
Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.
I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.
Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.
Great UI. Easy to navigate through CloudWatch logs. Simple setup.
Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.