XaaS — Everything as a Service: IT Architecture and Technology
Cloud computing and XaaS means a disruptive technological change; therefore, previous practices for designing, implementing, maintaining, and operating systems, must be redefined; this will require from the IT organization a prior commitment before the adoption of a cloud computing model.
Technology will have to incorporate into its strategic planning the new capabilities that will be offered by the cloud platforms once adopted. Its management, technical and operational processes should be redefined for extensive use. Undoubtedly, many of the traditional IT processes like portfolio management, project management, and others, will continue running, but now with additional tools.
For organizations that have decided to move their applications to the cloud, the impact will be different depending on the adoption and migration strategy that have been taken:
- For example, building the platform in the cloud from scratch, a model also known as a greenfield.
- Rearchitecting applications using best new resources, or brownfield model.
- Leaving the application unchanged and maintaining its original design, or “lift and shift” model (which is in practice an extreme variant of brownfield). In the latter case, there is the risk that we are transferring inefficiencies in the resource use or quality problems, and we will simply be passing on the bill, either to costs or to operational stability.
For those institutions that, -for different reasons-, favors a progressive adoption of as a Service solution, there are alternatives such as the IBM Bluemix Local Platform, that implements a PaaS on-premises service in our own datacenter, allowing the data to remain within the installation and protected by the user company’s firewalls.
All technological attributes that an application designed for the cloud should have could be covered in several manuals. As a reference, there are already some such as “Amazon Web Services — Architecting for the Cloud: AWS Best Practices” or the “AWS Well-Architected Framework” -which I highly recommend reading in both cases- and are important guides to how our traditional mindset to design solutions must change in aspects such as:
- We must design oriented to use the horizontal and vertical capacity scalability; but not only upwards, also downwards, when IT resources are no longer needed.
- Building applications oriented to temporary and non-fixed resources. Removing references and actions oriented to specific servers; even trying to recreate them multiple times -as many as we need- from configuration scripts (bootstrapping) of previously stored machine images, or through containers (like Docker).
- Extensively automating processes such as resource provisioning, instance retrieval, metric monitoring, continuous reconfiguration to reduce manual labor, with all the associated costs and risks.
- To achieve a loose coupling of the services, through agnostic interfaces (RESTful APIs). Using new design patterns based on asynchrony, fault tolerance, and achieving the “minimum viable transaction (MVT)” that guarantees, even a partial response to the user and instead of a complete failure in the face of a technical problem.
- Stop in guessing what the capacity required for our applications should be.
- Testing applications the most approximate to their actual scale in production, taking advantage of the cloud capacity to replicate systems at a lower cost.
- Accustoming to evolutionary systems architectures, which are data-driven, that is, we define and re-define them based on the measurement of how are performing in production; and not under the traditional model to do so only once during the design stage.
Another document that I find very useful is the so-called “The Twelve-Factor App”, which is a methodology for building applications “Software as a Service” kind, and that seeks to improve teamwork and reduce the time of incorporation of people to software projects, by clearly defining the integration of the different components into a solution of this type, reducing friction with IT Operations during the deployments and finally achieving a scalable application (which is one of the main promises of the “as a Service” architecture) .
Something important to understand is that XaaS environments will change constantly, new services will appear to improve the existing, or adding new capabilities, so a continuous prospecting of the technological offer is required to identify functionality that can potentially be incorporated to improve or redefine our current solutions.
There are solutions in the market such as Cognizant Cloud360 or CSC Agility Platform, -to name a few-, that become just the tools that help manage the complexity generated by having so many heterogeneous environments, automating, orchestrating, measuring, integrating this now complex environment.
The use of containers in the cloud is, for example, an excellent alternative for architecting solutions. Containers can generate for the IT operation the same positive impact generated by their physical pairs for the shipping industry by allowing to move the cargo with extreme speed.
Regarding data storage, the traditional model for permanently storing information (pervasive), are usually relational databases. For example, with PaaS, you can have a multimodal storage combination, depending on the nature of the information, the type of access required and the retrieval latency.
These are not the only tools and frameworks for modeling cloud architecture in our organization, the sky -and creativity- will be the limit.