Modern Infrastructure

The art of managing IT risk is never quite mastered

WavebreakMediaMicro - Fotolia

Get started Bring yourself up to speed with our introductory content.

Serverless architectures offer more than a catchy buzzword

There's an innovative concept behind the buzzword 'serverless.' Discover the benefits of this emerging architecture and how it delivers the true promises of cloud computing.

Serverless computing has become a popular yet confusing topic in the IT industry. The first time I heard the phrase serverless computing, I laughed it off as another meaningless buzzword. As an IT operations engineer, the phrase seemed baffling -- perhaps even misleading -- because it still relies on servers, right?

I laughed, thinking, "Try running an application without infrastructure," before the flaw in my logic smacked me in the head. I was thinking of serverless computing with an operations bias. Having spent decades in IT operations, it's no surprise that I was completely ignoring the developer's point of view. To developers, serverless architectures are a game changer. It's is more than a buzzword. It may be a terribly stupid name, but that doesn't matter.

Serverless computing is the platform as a service (PaaS) that developers have always dreamed about. As with most new trends, especially in software, we don't have a clear and consistent definition of what serverless actually is. The industry is abuzz with talk of serverless this and serverless that, but they all focus on a specific product.

To understand what serverless is, first we have to realize that it is a type of IT architecture and not simply a product or service. Serverless is a method of delivering IT services where the underlying compute resources are consumed as a shared opaque pool, rather than a server or container that someone must provision. That means application code doesn't run on a server, or even a container, but instead runs on this shared pool of compute resources.

While the notion of masking the underlying hardware infrastructure is a core principal of cloud computing, most other architectures have the concept of a unit of compute, usually a server or container. Serverless architectures have no such concept. It is a cloud platform model that can deliver the true promises of cloud computing: infrastructure abstraction, scalability, ease of consumption and value pricing.

To understand why this is such a game changer for IT, we need to understand the typical IT application landscape. We build web servers, database servers and application servers. The code runs on the server. This gives us a very server-centric view when it comes to an application and creates a central problem: The application is tied to some underlying hardware.

Typically, we've abstracted that server with a hypervisor, but that doesn't fundamentally change anything for the application. Virtualization is mostly about infrastructure abstraction and doesn't address the business need to develop and push code faster. Containers arose to address that need, but I see that as a stopgap to a long-term transformation. Containers or microservices are an easy translation to existing infrastructure constructs and, as such, don't fundamentally change us from a server-centric worldview. Moving to a microservices architecture has helped applications to be more agile and scalable, but at the end of the day, we've just made the compute construct smaller.

In serverless architectures, the code doesn't run on a server or even a container anymore. It simply runs on that shared opaque pool of capacity. For a while, there was a popular metaphor that compared legacy servers to pets. They had names, you took care of them and people felt a sense of ownership. Containers were more like cattle -- they didn't have names. And if one got sick, you sent it out to pasture. With serverless architectures, there are no cattle, only the herd.

When I finally started to understand the value proposition of serverless architectures, I still couldn't let go of the name. No matter how awesome the idea, the name still sucks. After all, we'll still have servers. CPU and memory are physical components that can't be completely abstracted away. When it all comes down to it, does the name even matter? We've hand plenty of stupid names in the IT industry. I have to learn to move on. It's just a name.

Serverless architectures fill the gaps left by microservices. The push for agility and infrastructure abstraction isn't going away. In fact, more abstraction is the way of the future. While serverless architectures are immature, there are plenty of PaaS platforms on the market. These services are far more mature than the serverless approach. PaaS still doesn't completely address the problem, but it will remain a stopgap until serverless evolves. As such, I think most PaaS offerings will grow into serverless architectures and make today's cloud model look old-fashioned.

Article 4 of 5

Next Steps

Reap the benefits of serverless in public cloud

Learn about Microsoft's serverless strategy

How serverless will change the game for IT ops

Dig Deeper on Emerging IT workload types

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How will serverless computing change your data center strategy?
Computing should be ubiquitous. Virtually no hardware.....pinging packets rapidly back and forth....the packets then live in the air...absolutely no need for servers or storage.
How about using a DB Serverless architecture?  Instead of using a DB Server, try hosting your Serveless database on a Windows O/S Server or Unix O/S Server.  As for the database architecture goes, try an ISAM-like, NoSQL implementation that costs you nothing in 3rd party software costs, nor end-user/site licenses. 

The merging of 2 relatively weak database technologies, so that the two, when working in tandem together, produce a relatively strong database technology.

Why not try merging:

 (1) Flat File "text" databases, with fixed-length records, for your important data storage. 

(2) SDBM binary key/value pair databases, stored on hard disk, that are tied to program hash tables in memory, for persistent, instantaneous, random access indexing to Flat File record offsets (in bytes).
Position the file pointer X number of bytes from either Top-of-File, or -X number of bytes from End-of-File. Then read your record into memory, modify it in memory, then overwrite that record "in place" within the Flat File.  

And yes, you can create your owning record locking method by maintaining a SDBM file (available in memory to every user for lookup and edit) that writes the user-name, flat file name, and record offset, of the record currently locked for edit by a single user, then releases that lock upon SAVE or CANCEL. 

And yes, you can store Bitmaps in your Flat "text" Files as "text", and convert them back in memory to images for display through a DB application user-interface you write. This is a great security feature. Routines are out there which you can find "for free" that do the conversion e.g. Win32::GUI::InLineBitmap from ActiveState ActivePerl.  This conversion tool has been around 15 or more years. Others likely exist in other programming languages.

Yes, you can compress your text data and encrypt it using a technique that maps "words" to codes (1,2,3, or 4 character codes in the range {a-z, A-Z, 0-9}. That is over 15 million, 1 to 4 letter codes.   "Words" are defined as any contiguous characters between white space (including punctuation).  You can persistently store the "word"/code mappings in SDBM binary file(s) which you tie to program hash tables for immediate random access and "word"/code conversion as each Flat File "text" record is read in to memory.   Assignment of Codes to "Words" is done randomly(by random seeding), so that any encryption operation on the same set of data produces a different set of "words"-to-codes in your SDBM mapping file(s). 

Or you may use a formula-based routine such as MIMEBASE64 encoding/decoding.  Although this increases the size of Flat File records, but is easier to implement, and requires no "words"/codes mapping file*(s).    

Get More Modern Infrastructure

Access to all of our back issues View All