When it comes to the future of IT infrastructure, service providers will need to support three types of customer applications:
- 1st Platform – monolithic applications
- 2nd Platform – Client / Server based and Service Oriented
- 3rd Platform – Microservices based
As I noted recently, microservices is the model that underpins the 3rd Platform, as SOA did for the 2nd and Monolithic for the 1st Platform. For microservice to work the underlying infrastructure capability has to support the microservice design pattern and have to focus on all relevant non-functional characteristics (availability, stability, reliability, performance and security). Microservices will require “infrastructure” out of the box which can be constructed in a “lego based” approach (see here our Technovision 2016). Infrastructure near capabilities like compute, storage, network as well as infrastructure related capabilities like load balancing, replication etc have to have a “plug and play” approach and the implementation should be invisible to the consuming microservice.
Infrastructure, or more precisely technical infrastructure, is the combination of all technical components needed to store, manipulate and transmit data used or consumed by information systems (applications) in a particular context, with a certain performance characteristics and against a set of so-called non-functional requirements.
To create “invisibility” for miroservices, infrastructure services have to comply with particular characteristics such as fully automated, utility based, software only (towards microservices with hardware underneath).
In detail it means that a microservices developer will have to have the ability to create, use, move, expand, contract and delete compute but also network and storage capability. This includes all “customer facing” infrastructure services. This is where concepts like convergence, hyper convergence and fully convergence infrastructure (or better software based) will be the template for many organisation to make use of microservices.
A Microservices based infrastructure platform will have to be fully software based. It means that control of the data centre is fully automated by software, meaning hardware configuration, storage provisioning, network configuration are managed through software. This is in contrast to traditional data centres wherein the infrastructure is typically defined by hardware and devices.
- Utility based: Utility-based infrastructure service delivery refers to the packaging of infrastructure resources, such as computation, storage and data transport, as metered services similar to traditional public utilities (such as electricity, water, natural gas, or telephone network). In other words: a utility IO service is a metered service supplied through IO's shared infrastructure, in which services are separated at a logical level.
- Software based: Not just compute but storage and network capabilities must be implemented using software only. All hardware capabilities should only cover bare minimum hardware capabilities like CPU, pure storage and basic network switching.
- Open Standards based: Invisible infrastructure services are based on "Open Standards" to facilitate interoperability and data exchange among different products or services, and avoid vendor or technology lock-in. "Open Standards" are standards made available to the general public and are developed (or approved) and maintained via a collaborative and consensus driven process.
- Virtualized: Independence from the underlying technology allows these services to be developed, upgraded, and operated in the most cost-effective and timely way. Otherwise technology, which is subject to continual obsolescence and vendor dependency, becomes the driver rather than the user requirements themselves.
- Service Oriented: Services provided by Invisible infrastructure services will be service oriented. Service oriented infrastructure intent is to prevent complex interfaces and therefore lead to cost effective operation of these services. Above that, Service Orientation is an enabler for Invisible infrastructure services to act as a Service Integrator and as an integrator of best-of-breed infrastructure services in the market in our delivery model.
- Horizontal and Elastic: Seamless (or preferably “step-less” or “linear”) scalability allows for solutions to grow or shrink in any required size. Step-less scalability supports the flexibility to expand growth, is an enabler for predictable cost, low effort growth in solutions and fit-for-purpose service delivery.
- Fit for Purpose: Fitness for purpose means that Invisible infrastructure services will provide services and solutions to our Clients to meet the articulated requirements, indirectly supporting our Client’s mission, but without squandering valuable resources.
- Sustainable: Providing sustainable Invisible infrastructure services and operating a sustainable infrastructure are critical aspect for a number of our Clients. It involves the re-thinking of asset purchasing, use and disposition, and goes beyond Green IT which is aimed at energy conservation to full lifecycle analysis.
- Fully Automated: Service provisioning and delivery is to be automated to drive cost efficiency in operation. By automating all repetitive tasks associated with managing servers, network, storage, databases and application servers, it supports the notion of end user based provisioning, supporting business users provisioning and unprovisioning Invisible infrastructure services.
- Lego-based Modularity: Invisible infrastructure services are to be based on modular and “Lego” based building blocks in order to reduce complexity and support multivendor strategy. Modularity also supports the separation of concern concept, which is aimed at avoiding duplicate functionalities.
- Globally Operated: Global clients are running a 24x7 global organization and microservices will deployed in a global context. There is a need in ensuring that the services are fully global to operate around the clock services and at a global scale.
- Secured: Any internal and / or external related activity has to be fully secure – meaning that only authenticated and authorized services, people or systems allowed access
- Fully SLA and KPI Cognizant: Services will have to be consumed / used according to platinum (99.999%) , gold (99.99%) , silver (99.95%) and bronze (99%) service levels as example. The infrastructure platform has to cater for all non-functional requirements.
Let’s use an example. A developer for a mobile application using C++ (could also be of course HTML5, Java) to construct a UI / App that can be deployed on Android and iOS. Putting functional requirement aside the non-functionals are tricky – global application with the need to provide fast, reliable and secure access to data from any location and with different SLA and KPIs – the client pays different tariffs depending on availability and performance. Also the development is using DevOps approach and duration from start of development to run in live is less maximal 5 days.
The decision was taken to use C++, and an IDE (Integrated Development Environment) was chosen – let’s say NetBeans and GIT for code version control. As this is an autonomous team there is a need to create, manage, control and delete development environments, SIT (System Integration Testing) environments, UAT (User Acceptance Environment) environment, as well as run live tests multiple times per day. Learnings from the tests will be taken back into development so continuous integration will be needed.
From an Infrastructure perspective the autonomous team will need to be able to start a server – let’s say it’s an Ubuntu 14.04 build that includes an apache web server, mysql database server as well as various other C++ written application components that are being developed at the same time by separate autonomous teams. Developers use a different Ubuntu distribution (or any other OS or that matter). With tools like Docker it will be simple to create an environment on the developer laptop or a different target platform by pulling down an image and dynamically create a container by simply issuing a “docker run –it ubuntu bash”
This will run a bash inside the container. Using docker native and/or other tools available the developers can simply update the image (with code or config changes), how often they like. And of course as this is a container there are other options available – for instance there is the possibility to connect capabilities like SOI and tools like docker to provide the autonomous team with the ability to create and construct the required pre-production and change / modify the production system.
For instance the developer can try changes and if not successful, can just simply restart the image as a container: to demonstrate we started a linux bash, deleted a program called “ls” (same as Dir) and just restarted the image again. As all code is running in complete isolation and the image file was not modified, any changes are quickly reverted. Of course there is a need for strong version control.
In order to achieve this the infrastructure has to be fully software based – maybe using OpenStack Nova to start, stop, etc., VMs (Virtual Machines), Heat to orchestrate (so move VMs from one to another location) and Cinder to manage data. As the team develops, tests and runs live services different VM images are needed in order to comply with the different service levels and therefor different infrastructure design. Whereas in pre-production no clusters / high availability is needed, in production this might be the case. To manage the live infrastructure you might use tools like Marathon and Apache Mesos to manage the server infrastructure. Docker could be the vehicle to manage and move code and data around, integrated into OpenStack and Mesos deployment.
Key behind all this is that Infrastructure is changing to become Lego based – to create and construct infrastructure services in such a way that any stakeholder can consume and orchestrate.
Thanks for Reading.
