Thinking Outside The Box

Eggsample Inc. has an in-house IT team. This team managed networking, hosting, application development, and all other day-to-day IT needs for Eggsample’s different departments. In the year 1997, they released an application for use by their employees internally. Along with their website, company database, payroll, and other software, this just ran on ‘The Box’.

‘The Box’ was one massive work of computing machinery. All the parts of all the applications built and maintained, perpetually ran on ‘The Box’. It lived in a frigid environment, and was pampered, to say the least, by a small team of engineers. ‘The Box’ was wired to provide telemetry about various indicators of its health. Over time, ‘The Box’ became very brittle. It was impossible to carry out any reliable development or maintenance activity. With front-end, business logic, and storage co-located, it became impossible to reliably point out where failures originated from.

Years passed. Eggsample’s IT team changed their strategy and introduced multi-tier architecture. ‘The Box’ was phased out, and in its place, three smaller boxes, each of which were responsible for specialized functions were introduced. All the smaller boxes were instrumented and data about their operations were reliably captured. Isolating failures and focused maintenance activities became possible. Activities to improve and optimize the front-end, the business logic, databases, and storage were all carried out independently. There were now several smaller boxes to maintain, but it was a good trade-off.

Over time, the needs of the different teams began to change rapidly. This meant that servers needed to be provisioned and purged at very short notices. It became impossible for the IT team to keep track of the requests for new nodes and reliably set them up or tear them down. Fortunately, “virtualization” was just around the corner, and they introduced Hypervisors. With a finite number of physical boxes which had a long lifecycle, they could provide the different teams with multiple servers on short notice. They load balanced virtual servers to scale with demand. Separation of different application tiers was still possible. By attaching monitoring to each of the underlying nodes, system conditions were known. However, one important change appeared – it was not possible to determine how many servers were operational without running a check on the system.

The arrival of the cloud created a paradigm shift in the way the IT team at Eggsample Inc. operated. They swapped their physical infrastructure for infrastructure on the cloud. This allowed them to scale on demand. From using terms like nodes, servers, and the like, conversations about infrastructure began to include topics like images, instances, volumes, and snapshots. Spot instances, fleets and on-demand instances changed the way the team thought about their infrastructure. The rift between nodes and servers became wider when the team went down this path.

Eventually, the IT team at Eggsample Inc, decided to adopt microservices. Moving to microservices made this already wide rift in determining nodes, much wider. With several nodes holding up each individual service, and multiple services replacing bigger parts of the application, it became impossible to keep track of the exact number of nodes required to keep applications running in production.

Today, the team is considering migrating certain portions of their application to dynamically provisioned cloud functions (aka serverless) and the remaining to container-based architecture. While containers come with an abstract notion of nodes and servers, the concept is entirely extinct in the realm of serverless architecture.

As a result of these shifts in how infrastructure has moved away from a notion of “boxes”, it is unrealistic for software vendors to continue to price on a per-node basis. Scaling prices linearly by the number of nodes will push the price of software to a detrimental level. Dynamic provisioning changes this to a fuzzy model where the variation makes it impossible to work with. Vendors are therefore left without answers to the question of which ‘box’ do we attach our software to.

At Plumbr, we are committed to the success of engineers and engineering teams the world over. Our mission is to help make web applications faster and more reliable. To keep up with modern development and operations teams, we have altered our pricing as well. We have moved away from the notion of boxes too, since they do not make sense any more. Instead, our pricing tiers will reflect the usage of applications. Here is a link to our new pricing page, which has information about our new tiers. We welcome any feedback, comments, and observations. You can enter them below or email us at support@plumbr.io.