December 17, 2013 | Written by: Joshua McKenty
Share this post:
Businesses have IT to provide apps that will deliver value to their customer. Sometimes this has a direct value to the customer and sometimes an indirect value, like an internal app made for managing sales, marketing or even HR. Either way, the idea is that the app will make the business more efficient and responsive.
IT used to be solely responsible for developing, purchasing and operating these apps. But today, every team in the business is writing apps, and every part of the business depends on the apps that they run. Today there are more apps than ever, and they have gotten bigger, more complex and more mission critical than before.
In fact, we are long past the point where any modern application is a single piece of software. Most apps these days run on top of a collection of common services, such as web servers, database servers, queue servers—even the storage space and network connections are increasingly consumed as-a-service by apps.
IT has gone from the “back of the class” to the front of the boardroom. And the purpose of IT has been transformed in its evolution from operator of apps, to provider of the services that power them.
Its evolution begs the question: what’s different for IT as a provider of services?
First, it’s about scale.
Second, it’s about efficiency.
Third, it’s about speed.
The era of scale out
Explaining the difference between scale-up, and scale-out, is beyond the scope of this post. But I encourage you to read Maged Michael’s excellent summary of the topic. As our businesses have become more and more dependent on IT apps, we can see that those apps are in turn more and more dependent on scalable, efficient services.
But whether we’re scaling the number of users, the amount of data, or the complexity of calculations required—or even if you’re scaling all three—the era of “scale-up” is drawing to a close. And if we can’t scale UP, we have to scale OUT. This means building multi-server distributed systems, which are notoriously tricky. (In fact, it’s so tricky that even Google touts their expertise in scale out as a competitive advantage.)
If we step back, and take a look at why it is so important to scale out, we see that when we invest in developing a system for delivering a particular service, we’re likely to try and get as many different apps to share that service as possible. Standing up new and collaborative apps will take less time and less effort. This is the same type of thinking that encouraged object-oriented programming and object-oriented reuse and arguably the birth of OpenStack.
If we’re all sharing the same system, we can invest more in making it as reliable and efficient as possible. I like to call this the “Warren Buffet” approach to enterprise architecture—put all your eggs in one basket, and then watch that damn basket! ( Note that although we might commit, at an architectural level, to using a single common service—that doesn’t mean that service should be run only in one location, or using only one code base. Embrace simplicity, not single-points-of-failure.)
How to adapt to the era of scale out
As applications have gotten both larger and more complex, IT has had to focus more on the services that can power these applications rather than just the applications themselves.
Now, technology doesn’t necessarily make life better. Nor does it reduce the number of mistakes we make. But it does help us go faster, which means we can make mistakes at a faster and faster rate. This need to go faster is what’s happening in business too. The bottom line: IT has sped everything up.
The pursuit of speed in IT has been transforming everything about how we develop software over the past ten years. It started with our project management methodologies, like switching from traditional systems development life-cycle approaches to Agile software development, such as Scrum or Kan-Ban.
As we sped development up, we needed to integrate and test our systems earlier, and the continuous integration ecosystem was born, with tools such as Jenkins and Build Bot at the heart of it. Eventually, the need for speed broke through from development and testing into production environments. Thus, the DevOps movement was born. ( We’re starting to see a raft of tools and technologies to support Continuous Deployment now—the most mature form of DevOps.)
The final step in this metamorphosis is a revolution in the delivery of the underlying infrastructure services—the push to API-driven, or software-defined, …well, everything. The explosion of apps across the business is driving the need for cloud services today that are built on an open platform.
Only when continuous infrastructure supports the continuous deployment of continuously integrated and continuously prioritized apps and features, will our work be complete.
For more of my thoughts on apps and services, open source software and how to manage your IT infrastructure like 400-head of Holstein cattle, check out my blog at http://www.pistoncloud.com/blog.