The SaaS-ificiation of Code...

.. and the rise of the API

I know it’s hard to believe but I used to write code. I would never consider myself a developer by trade but I’ve gone through enough education, created enough code from scratch, and built and broken enough applications to have a strong foundation. I’m also experienced enough to know a bit about the history of application development and how things have changed over the past two decades of writing software. What I can promise you is this: we have only just begun to see the impact of these changes. The future will be forever changed due to the “SaaS-ification” of code.

We used to write code

Way back when people used to actually write code from scratch, development was tough. It was really tough to be exact. It was almost like staring at a blank page and thinking about writing an entire novel. It’s a scary proposition, but that’s how we used to do it. I’m not quite old enough to have seen an era where no libraries were in use but in general, most of the modern code abstraction layers hadn’t been built and only a few useful libraries were around to make our lives easier. We had to learn how to build algorithms from the ground up to deliver the computational results we desired. Somewhere along the line developers decided to share the code they had written so that each person didn’t have to reinvent the wheel. These libraries were packaged up and shipped along with development environments or downloaded from the fledgling Internet to help a developer write their own code more quickly.

Then we assembled libraries

Eventually, the library and code reuse paradigm became so prevalent that we started writing less and less code from scratch and instead began to focus on the assembly of libraries to do what we needed. We might still occasionally have to create something from nothing but much of the heavy lifting was done for us. We just needed to search and discover what someone else had done and reuse it. Entire communities grew around this concept allowing developers to help and share with one another to lower the burden of getting their jobs done. The total number of libraries available for developers grew so large that entire distribution systems, naming conventions, community rules and guidelines, and even security tools began to spring up to support the movement. While we still have to periodically “code” in the traditional way today, the bulk of what we write glues together components created by the people that have come before us.

Application counts are soaring

I am sure that at this point you are “thanking” me for yet another “history lesson”, but I swear there is a method to my timeline-based madness.

In another article I recently wrote called “The Atomization of the Application”, I go over in detail why there is an ongoing massive increase in the number of applications that enterprise businesses are having to support. Microservices, functions as a service, application workloads, and application counts, in general, are all skyrocketing and they are doing so at an exponential rate. We are witnessing the big bang of application growth!

As we “atomize” our applications to their smallest functional components, it makes logical sense that those small functional components are delivered via API from any provider, both in-house and outsourced. Each of these tiny applications can be containerized and wrapped into its own little abstraction layer as well. The concept of making calls between application functional components as separate APIs is becoming the dominant model for application development today.

The SaaS-ification of libraries

By moving libraries to APIs and microservices that we own and run, we are abstracting away the infrastructure that is supporting the smaller functions of the application. As we containerize these components and give them the ability to be run anywhere, in any cloud system, we are effectively taking the idea of the code library, turning it into a function as a service, packaging it up into this reusable approach, and moving it up the technology stack eventually turning it into an internal API.

Today, almost every application I see is written with an “API first” approach. There is a clear separation between the presentation layer and the data layer with the more prevalent communication model being the API. Often times there isn’t even a need for an API as component-to-component communication continues to grow.

Once developers realize that the packaging up of libraries and their maintenance as APIs can be outsourced, we will begin to see massive adoption of outsourced API-based offerings. Third-party companies will look at what common libraries are in use and make them accessible as services that can be charged for on a consumption-based model. This will be especially true in the short term wherever the API can be coupled with large data chunks so the developer won’t have to maintain that dataset as well.

We have already begun to move libraries into a software-as-a-service model (SaaS) as represented by the growing number of service APIs available for developers to use (e.g. Rapid’s API Hub). As the adoption of service APIs grows, this will lower the administrative burden of the developer even further.

What it means to cybersecurity

There are large-scale changes in technology once every handful of years. The shift to the cloud, the creation of mobile devices, the invention of the Internet… I could go on. Each of these shifts of the tectonic plates of technology has caused a ripple effect of change in how we approach cyber security. As we monitor the growth of SaaS-based access to what were once library functions we will see an equivalent impact on the way cyber security gets done.

The SaaS-ificiation of code will result in a massive increase in the need for API discovery, monitoring, governance, detection of attacks, and automated workflow remediations. A number of companies have been born in the last few years to tackle this problem including Noname Security, Salt Security, and Traceable.ai. These security startups have recognized the need for API governance and security solutions for the code we write as well as the APIs that we outsource to others. API security is the next revolutionary wave of cyber security to automate the cybersecurity of our application space and it’s all due to the atomic deconstruction of our applications and the rise of SaaS-ification of our libraries.