Can you end meeting dread by having stand-up meetings? IT leaders say it's not as hard as you'd think - and delivers big benefits.
Ask almost any business or IT executive their biggest goal right now, and you will often get the same answer: “We need to be faster and more agile.”
From CEOs to developers, everyone feels the need to respond more rapidly to customer requests and to the moves of rivals. Companies feel they must be able to disrupt the status quo – quickly – or face being disrupted by competitors. But after years of talk, some companies are truly accelerating. How can you be one of them? What are these companies doing differently?
These companies work in a truly agile way.
Agile and the DevOps methodology – based on small teams and rapid experimentation – is not new. But while agility and modularity have long been valued, three trends are converging to make superstar-level agility possible:
These three factors solve problems IT has grappled with for a long time. What makes this point in history so special, however, is that this convergence is happening at a time when business has never been hungrier for speed.
As an IT shop, taking advantage of any one of these factors will be a good step toward gaining agility. But capturing all three will increase your gain exponentially.
Let’s look at how to tap into all three factors right now – and explore what’s coming for each trend in the near future.
The cloud allows programmatic access to resources. You can use application programming interfaces (APIs) to manage and allocate resources per app, and use automation to deploy those apps at scale across test or development environments (in private or public clouds.) In this way, APIs and automation help to unlock the dynamism of cloud computing.
However, when it comes to agility and modular software development, technology is not the most difficult challenge. The biggest hurdle is typically organizational change – the shift in mindset required.
[ Want advice on this hurdle? Get the free download: Guide to IT Culture Change. ]
For example, some companies roll out a new infrastructure with the expectation of moving much faster, only to find out that benefits are marginal. The real bottleneck turns out to be something unanticipated, like a weekly meeting to approve a relatively minor technical change to a application. These sorts of often overlooked details can hamper overall success. To achieve your potential, you must uncover these bottlenecks in internal processes – and it’s not easy.
However, speed and agility are not optional anymore, but required. Think of it this way: Companies born in the cloud are defined by software and technology and have learned from birth to move faster. Part of moving faster is building apps in a way that decouples large teams into smaller teams: Every team moves at a level of independence, supported by cloud resources. These companies and teams are not trapped by inertia. Small teams can really move.
Agility will progress to a new level as software architecture continues to evolve.
Microservices and containers start us moving toward an important goal: Eliminating a larger set of responsibilities from a developer so they can really focus on solving a specific problem.
The next step on this spectrum is serverless technology. Serverless offers a way to encapsulate simple functionality to respond to an event. A classic example would be uploading an image to a cloud storage service: This event triggers functions, like image inspection and labeling, creation of thumbnails, etc. Automation and APIs help make this possible.
[ See our comprehensive resource: Hybrid Cloud: The IT leader’s guide. ]
Developers have become essential to the decision-making process of the business – because more and more, business value is derived from software. Given this reality, IT leaders must understand what their developers deem most critical to their success. Here’s where microservices come into play.
Developers, tasked with moving rapidly, need one fundamental thing – not to be blocked. They need to be able to manage their own destiny, which likely looks something like this:
Developers don’t want to wait for a “blessed” image, cloud resources to use, or network infrastructure needed to connect services. All of these things can block the developer, as can compliance processes.
As you build a microservices architecture, you have a collection of services that connect via APIs and combine to become an app. Then automation helps the app work at scale. But the individual developer doesn’t have to worry about how the app scales: The developer only has to focus on what matters – the particular microservice they are building.
Where will the microservices come from? They can be built in house, be a part of a platform, or be third-party external services (think SaaS.)
Microservice value grows with time: The more you have services available through APIs, the more rapidly you can assemble apps from those services.
This scenario requires secure, authenticated, encrypted communication paths between services, as well as policy around the quality of service from the APIs involved.
[ Also read: When not to do microservices. ]
At Red Hat, we’re working to put those network-centric needs into the OpenShift platform level, and contributing to the open source Istio project, which provides a uniform way to connect, secure, manage and monitor microservices. Today it works with Kubernetes environments, but support for VMs and other environments is coming. We expect similar functionality to be possible on top of serverless environments via the OpenWhisk project.