The tech stack has a problem. It’s serious. It’s pervasive. And it’s insidiously hard to spot.
Look at a typical tech-stack diagram; infrastructure at the base, platforms and middleware services above, applications at the top.
Everything seems in order? The parts are all there. The diagram reflects how most organizations approach IT: infrastructure first, then platforms and services, finally applications.
So what’s the problem?
The problem is that this picture—this way of thinking—is completely upside down.
Why Infrastructure-Centric Thinking is Outdated
Infrastructure is the last thing users care about, but it’s the first thing many IT professionals think about.
And there was a time when that made sense. Infrastructure used to be expensive and slow to deploy. If you were a developer, it was the stone in your shoe, the fly in your soup, the Demogorgon that ate your favorite TV show character (#gonetoosoon #justiceforBarb). You had to think about it whether you wanted to or not.
It’d be great to have that feature, but our data center wouldn’t be able to handle the load.
We have to take the application down for server maintenance.
Until we create a cloud infrastructure policy, we are going to maintain legacy application architectures.
Applications Power the Experience for Customers (Internal and External)
But the cloud changed all that. It offered instant deployment and elastic scale, even as applications were becoming more important than ever.
Consider how banks interact with customers. As little as 15 years ago, almost every major customer transaction happened in-person, at a branch location. Banks’ IT teams only needed to support internal customers. Since then, while internal IT consumption has soared, those same IT teams now need to support robust online and mobile experiences for external customers like you and me.
Today, customers perform most of their transactions on the Web, or with smartphone apps. They don’t see this as a luxury or a premium service. It’s a minimum requirement for banking.
The same pattern holds true across industries. Applications are driving revenue, productivity, performance, and a better experience for all the customers that IT serves.
Embracing Application Centric Infrastructure
Clearly, you can’t deliver applications without infrastructure. But you can build a general-purpose infrastructure with technology that eliminates the need to provision, install, and maintain support for each application.
That means you can focus on results rather than requirements — outcomes rather than inputs. You know the capacity will be there, you just have to figure out how to use it.
So what does an application-centric infrastructure consist of? Some options include:
1. Hybrid and Multi-Cloud Environments
Hybrid and multi-cloud environments offer a heterogeneous computing environment consisting of private, on-premises computing resources and public cloud resources that use orchestration to create a seamless user experience. This model allows IT organizations to extend their data center and choose infrastructure that can best serve the application (instead of being locked into a single infrastructure environment).
Some of the benefits of using hybrid or multi-cloud environments include:
- Geolocation/Performance. Applications need to be accessed by end users from all across the globe. With multiple clouds hosted in different geographical regions, enterprises can deliver applications and services to customers with greater stability. Redundancy across geos can also help with disaster avoidance and recovery if one production environment is disrupted.
- Compliance with Consumer Protection Regulations. Hybrid and multi-cloud environments offer the speed, flexibility, and agility needed to fulfill governance, risk management, and compliance (GRC) regulations.
- Choice of Services. Just because end-users don’t care about your cloud infrastructure, that doesn’t mean the choice is meaningless. Many cloud providers differentiate themselves with specific services for hosting applications (e.g. AWS’s Elastic Beanstalk or Lambda). Choose the cloud(s) that provide the best experience for your customers.
2. Containerized Applications
Applications are traditionally deployed on bare metal or virtual machines (VMs), which allow one server to function like several smaller servers without additional hardware. VMs were long considered the most modern way to subdivide a server’s computing power.
The next evolution in application deployment is containers. Containers, like VMs, are defined by software. Unlike VMs, they’ve abstracted away all dependencies on hardware. They don’t simulate an entire machine; they’re just an environment with everything needed to run a particular application. Because containers are self-contained, they’re incredibly portable. A containerized application running in a test environment on your laptop can be easily moved to a data center or cloud environment with minimal effort. Doing the same for a VM or monolithic application could take hours or days. Containers are ideal for application-centric companies because they don’t depend on any particular infrastructure.
3. Applications Deployed as Microservices
The popularization of containers is closely related to another trend: microservices. Until recently, developers designed applications one of two ways:
1) As a large, individual application known as a monolith or
2) As a coarse-grained application with a few interdependent services known as Service-Oriented Architecture (SOA).
Both types of application received updates once or twice a year, as the effort was non-trivial and disruptive.
Have you ever tried to use a web-based service (e.g. bill pay, appointment scheduling) that was down for maintenance? They likely used one of the two architectures mentioned above. When a monolithic or SOA application is getting updated, it needs to be taken down so the new application can take its place. Getting the updated version of the application into production can take hours, which is why it usually happens overnight or during the weekends.
A microservices architecture breaks big, bulky applications into smaller, interconnected services that run independently. Facebook.com is a good example of this. The site is never “down for maintenance” and is constantly receiving new features. Teams are assigned to different aspects of the site—feed, chat, live stream, events—each operating as an independent service, or microservice. Updates to any service don’t affect the rest of Facebook.
The big advantage to microservices is that they make development, testing, and deployment of individual services much faster and easier, as each new service is far less complex than a monolithic application would be. They also allow individual services to be taken down independently of one another for maintenance/updates. The end result is that microservices can offer a better experience for customers than previous application architectures.
Find Partners and Vendors That Support Your Application-Centric Strategy
A production-ready application environment takes more than just cloud infrastructure. You need dozens of application, network, and infrastructure services to ensure the performance, availability, and security required for a good customer experience. It’s not an easy transition.
Many vendors you’ll run across built their legacy in the data center. They’re modernizing their appliances to run in the cloud, and in many cases, they’re little more than hardware devices simulated in software. They still need to be manually provisioned and configured and lack the self-service, automated, and elastic characteristics of their cloud native counterparts.
How do you separate truly application-centric vendors from the pretenders? Here are seven criteria:
- Elasticity. Can the solution scale elastically with your application, or will it be a bottleneck?
- Portability. Can the solution move with the application across environments, or do they need require different versions of the solution depending on the environment?
- Automation. Can the solution automate deployment, configuration, and scaling of the service, or does it require you to manually manage the service?
- Self-Service. Can the solution provide self-service functionality for developer and operations teams, or does it need to be provisioned manually?
- Resilience. Can the solution provide high availability through elastic architecture or does it rely on redundancy?
- Analytics & Visibility. Does the solution provide visibility and analytics on end-users, application, network, and infrastructure, or does it operate as a black box?
- Centralized Management. Does the solution provide a single portal to control all instances of its service, or does each instance require independent management?
Vendors that score well against these criteria are application-centric — and your best guides out of the infrastructure Upside Down. Discover for yourself the difference in an application-centric infrastructure. Compare Avi Networks with F5 and Citrix Netscaler and break free from the infrastructure Upside Down.
Avi Networks prides itself on delivering application-centric load balancing and web application security solutions. Schedule a demo and see how we stack up.
