The Future of the Enterprise is Serverless
Photo by Sweet Ice Cream Photography on Unsplash

The Future of the Enterprise is Serverless

Serverless is the new way of doing software development and architecture. It means moving away from thinking about servers and containers and leaving that to the cloud vendor. Instead, you focus on features and business value and use FaaS (functions as a service, e.g. AWS Lambda) and other managed cloud services to build powerful applications and APIs. Serverless allows you to do more much faster.

But how can we say with certainty that mass adoption of Serverless is coming to the enterprise?

To really understand where the enterprise is headed, let’s first take a brief look into the past. In 2000, I built enterprise applications using the technologies of the day —Java servers and clients, relational databases with stored procedures and CORBA for distributed communication and interoperability. Deployment was every three to six months and required weeks of planning and an outage period. Looking back, early 21st century development feels comparable to the early days of agriculture. Of its time, it was revolutionary. By comparison to what came later, it was slow, unwieldy, inflexible and labor-intensive.

Enterprise Software Development ca. 2000 (or "Ploughing with Oxen", George H. Harvey, 1881)

In that era, standards, tooling and deployment was owned and governed by enterprise leaders like Sun Microsystems, Oracle and Microsoft. Vendors were only just starting to figure out interoperability and produce unwieldy standards.

The increasing appetite for open standards can be attributed to the open source movement and early, major drivers like FSF, GNU/Linux and Apache. The shift towards open source caused a crucial, irreversible change in the way enterprise software architectures were defined. Suddenly, open source empowered hobbyists, startups and academics to innovate quickly, share and iterate with unprecedented frequency. Now, we let the combined power and agility of the community demonstrate working, pragmatic solutions that not only worked right away, but continuously improved at amazing pace.

The democratization of enterprise architecture was fueled further by the rapid rise of the cloud. On-demand compute power from Amazon, Google, Microsoft, Heroku and many others made it affordable and fast for individuals and cash-strapped startups to build truly innovative projects and have a disproportional impact on the industry. Critically, we starting looking to the most innovative end users of software tooling for leadership, not the enterprise software vendors. The fast-growing innovators like Netflix, Twitter and Google gave leadership, knowledge and tooling. At the same time, smaller players and individuals continued to punch well above their weight, giving us game-changing offerings like Git, Node.js, Docker and MongoDB. Every step forward has allowed enterprises to build more complex systems much faster.

Over the last five years, enterprise software architecture has headed towards microservices. The three big drivers of this were cloud, containers and community. 

  • Cloud infrastructure like AWS gave us the ability to quickly and cheaply deploy and destroy secure clusters of machines with high availability.
  • Containers (Docker) gave us the ability to build, package and deploy immutable units containing software at a microservice unit of scale. Previously, it wasn’t feasible or comprehensible to deploy a few hundred lines of code as a single unit! 
  • Community offerings gave us the tooling to manage the new form of complexity that emerges when you start dealing with numerous, small units of deployment.

In order to do microservices effectively, new thinking, tooling and infrastructure was required. This turned out to be a substantial investment in time and resources. An architecture required dedicated effort to deal with orchestration and deployment. Even the big investors in this space, Netflix, evolved a standardized set of tools, techniques and libraries to make production microservices sustainable. This often amounted to building your own PaaS in order to get to a point where the microservices benefit pays off.

The Serverless Era, in one way, is just an incremental step forward from the era of container-based microservices. However, the evolutionary step of removing the need to manage container infrastructure, orchestration and scaling has massive benefits for the enterprise. The phenomenal pace of innovation at Amazon Web Services (AWS) in Serverless means that the infrastructure burden is being quickly removed and replaced by à la carte managed services.

At fourTheorem, we have a Serverless-first approach for new projects. Naturally, there are exceptions are for specialized computation and for some legacy systems. Even with legacy systems, Serverless is being introduced incrementally to help rescue large, chaotic, monolithic systems and enable those systems to start evolving again at pace.

To chat about anything in this article, get in touch on LinkedIn or via fourtheorem.com




Thanks for sharing Eoin. One thing that really resonated with me is 'servelress first for new projects'. Serverless is one of these shifts that doesn't lend it self to 'lift and shift' and embracing it means you need to think serverless from day one of the app design which by definition almost means 'new app'

Love the graphic...the conclusion ties nicely with the announcement of SAM offering from Amazon to better enable teams to visualize what they can deploy with serverless and some common pattern defined for use

I’d like someone to show me a case study for a successful implementation of a large system as a flurry of functions on FaaS and what are patterns and best practices for managing the complexity of such a system. It shouldn’t even take a large system to arrive at potentially thousands of those functions. So assuming we would embrace best practices of functional programming, which functional programming patterns would we adopt to compose software, and how easily would they be adaptable to a serverless system?

Like
Reply

Excellent article Eoin, thanks for sharing

To view or add a comment, sign in

More articles by Eoin Shanaghy

  • Why Observability Matters for Your Business

    If you haven’t heard the word “observability” used in your IT organisation, that’s about to change. What does it mean?…

    1 Comment
  • Why you should write a technical book

    Everybody has at least one book in them, they say. That's probably true of anyone working in software development.

    7 Comments
  • Your Developer Skills Shortage is Not the Problem

    Established software organisations seem to inevitably arrive towards a point where making progress becomes increasingly…

    6 Comments

Others also viewed

Explore content categories