Hyperscale public clouds are well established as the new platform for systems of record. Providers of ERP, supply chain, marketing, and sales applications are today predominantly or exclusively based in hyperscale public clouds. Oracle alone has thousands of customers for its front-office and back-office SaaS. And the list of customers is growing at a rate far exceeding that of traditional front-office and back-office applications.
Hyperscale public clouds are also, of course, a proper place to run new cloud-native applications that enhance or extend those system-of-record applications. These new applications are architected differently. While systems of record are typically large, monolithic applications running in virtual machines in the cloud, cloud-native applications are usually written as microservices, packaged in containers, and orchestrated to deliver a complete application to users. Among the benefits of this approach:
- Faster innovation
- The ability to provide specific customization for each application use
- Improved reuse of code
- Cost savings versus conventional virtualization due to the greater deployment density of containers and more efficient consumption of resources
All of this is common knowledge, endlessly touted, no longer debated.
Less discussed, however, is the galaxy of applications that aren’t necessarily suitable for centralized hyperscale cloud deployment. Instead, these applications thrive in distributed computing environments, potentially based on cloud services, at or close to the edge of the network. These applications are systems of engagement and systems of control.
Systems on the edge
Systems of engagement have been defined, by a leading industry analyst firm as “different from the traditional systems of record that log transactions and keep the financial accounting in order: They focus on people, not processes ... to deliver apps and smart products directly in the context of the daily lives and real-time workflows of customers, partners, and employees.” Systems of engagement, which are designed to facilitate human interactions, are inherently more decentralized than systems of record.
A third type of application to distinguish is what I’ll call systems of control. These applications provide real-time control between intelligent devices. Perhaps the classic example is that of self-driving vehicles. If two cars are speeding down the highway at 65 miles per hour, they are not going to automatically coordinate their spacing by sending data about velocity and position to a remote data center for processing. They’re going to communicate directly with each other, responding in microseconds. Whether for speeding automobiles, manufacturing assembly lines, or robotic surgery, minimizing network latency is a key issue for the internet of things.
Developers who are building systems of engagement and systems of control also are embracing the devops model based on microservices and containers. For these kinds of applications, containers offer:
- Near-zero cost of deployment across large numbers of systems (think hundreds of thousands of vehicles)
- Fast startup times, with instant replay and reset
- Greater portability due to reduced platform compatibility issues across possibly many different types of computers on the network
Where will these containers run? For systems of control, containers will typically run in the intelligent devices themselves -- for example, inside a self-driving car.
To run systems of engagement, enterprises will need to stake out digital real estate at the edge of the network close to their customers, employees, and partners -- not in hyperscale clouds, but rather in much smaller clouds suitable for lightweight container-based applications. Call them cloudlets.
Enter cloudlets
Cloudlets are a way of moving cloud computing capacity closer to intelligent devices at the edge of the network. As Carnegie Mellon researchers define cloudlets, they are the middle tier of a three-tier hierarchy: intelligent device, cloudlet, and cloud. Cloudlets can be viewed as a datacenter in a box, with the goal to bring the cloud closer to the device. Building on the CMU researcher’s ideas, I believe that cloudlets should have four key attributes:
- Small, low-cost, maintenance-free appliance design, based on standard cloud technology
- Powerful, well-connected, and secure
- Maintains only soft state (built for microservices and containers)
- Located at the edge of the network, close to the intelligent devices with which it will communicate
The implications are significant. For example, while many people have a vision of the virtual enterprise running applications centrally in a single hyperscale data center in the cloud, the reality is that innovative companies will deploy engagement and control applications in hundreds or potentially thousands of cloudlets globally.
For a retailer, it may be obvious where to place the cloudlet infrastructure and the containers they run: in the retailer’s outlets. For other businesses that don’t have a local brick-and-mortar presence, telecommunications providers offer cloud services in metropolitan datacenters or even as geolocally as the nearest cellphone tower.
In effect, rather than owning hundreds of datacenters wherever a presence is wanted, businesses can rent a sliver of a cloud for a period of time -- effectively a hotel room for their application in a local datacenter. The application checks in and out as needed by the people, devices, or sensors at the edge of the network.
Herding containers
Another important implication: The traditional, manual approach to fixing problems gives way to automation. With hundreds or thousands of containers pushed to vast numbers of cloudlets, the days of troubleshooting in production are over.
Have a hardware failure? Autoscaling containers can automatically launch a new container on redundant cloud hardware as needed. System software failure? Defective containers can be culled and a new container loaded. Application software failure? Fix the source once and push out a new wave of containers globally. Never patch or upgrade containers in the field.
This is called the “cattle versus pets” model of application deployment and management as described by Gavin McCance of CERN. Pets are unique. They are hand-raised and lovingly cared for. When they get ill, you nurse them back to health. Much the same can be said for traditional OLTP and decision support systems built with massive, complex monolithic applications.
On the other hand, systems based on microservices and containers are treated more like cattle. Cattle are almost identical to each other. You may have hundreds or thousands of them. When one gets ill, you replace it with another one.
So the fundamental view of IT operations for container-based systems of engagement and control is different. IT will produce many containers and push them out to cloudlets close to users and data for short-term use, typically hours or days. Should a container have a failure or become outdated, it’s not patched or upgraded: It’s deleted, and a new container is pushed to the cloudlet.
For a business to function as a cohesive whole, the systems of record, systems of engagement, and systems of control will need to be integrated. A common infrastructure for the entire lifecycle -- develop, build, distribute, monitor, and manage -- can be used to build and deploy distributed cloud services in the form of containers. Large monolithic SaaS applications won’t go away, but they may be the exception, not the rule.
The technologies needed to make this concept a reality are coming into focus. There is a growing recognition of the importance of having a suite of tools that simplifies the lifecycle of container development, deployment, and management.
Microservices-based application development typically relies on tools such as scripting languages, development frameworks, source repositories, bug tracking tools, continuous integration tools, and binary repositories. Other tools package and deploy microservices as containers. Management tools for deployment and configuration are designed for frequent implementations of identical services across identical servers. Orchestration tools are used to create logical collections of containers that belong to an application for cluster management, scheduling, service discovery, monitoring, and more.
Many companies are delivering these tools, and industry standards are beginning to appear. Ultimately, these tools and standards can enable enterprises to operate a virtual datacenter composed of many cloud services across potentially dozens or hundreds of physical datacenters.
How can you get started on this larger vision of a virtual datacenter? There are two immediate steps. First, get your systems of record to the public cloud and free up your internal resources to focus on new innovative systems of engagement and control. Second, establish a devops discipline within your IT organization. Both steps can be long and arduous, but they can pay for themselves as you go. At the end of the journey lies a virtual datacenter with the scalability, reliability, and responsiveness necessary for a true real-time enterprise.
Robert Shimp is group vice president of Linux and Virtualization Product Management at Oracle.
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.