Software defined open infrastructures require architecture

Software defined open infrastructures require architecture

Software defined open infrastructures require architecture

Open source software is taking over the world, driven by – and at the same time driving – the innovations of cloud technology. Open infrastructures have become the biggest cloud solutions that companies use for their private cloud, as well as a solid base under most of the public clouds. But the only way organizations can provide a consistent and measurable level of quality for their cloud, is by a solid design. And that is where we see that most problems arise.

 

Software solutions to create your own platforms Open infrastructures are almost by definition ‘software defined’. This firstly means that the solution is available as software code to run on generic hardware. But most of these software packages are not the actual solution itself: they are software to design and build the solution you think you need. With Ceph any organization can design and build a storage solution using Ceph software. Or ‘define’ a compute cloud using OpenStack or OKD. Or define a networking platform with Cumulus software.

 

The only way to design a consistent level of quality of your cloud platform is to design by architectural principles. To prevent exclusions, favoritism and inconsistency and resolve any conflict between these principles. And for cloud platforms, the main principle is that platform customers are able to remain using workloads no matter what interruptions or developments in the infrastructure.

 

Implications of architectural principles

The main cloud principle has very important implications for the design and maintenance of your platform. Some of which are that your cloud should always be able to scale out or in, add innovations and the premise that during its lifetime, any component will fail. A well defined architecture enables innovation by integrating new features such as container platforms and charge back costs to users. An added benefit of a good architecture is that it will leverage all investments in your current platform, your team’s cloud platform knowledge, datacentre facilities and hardware as well as your users’ investments in deployment templates.

 

At Fairbanks as well as 42on we have defined the most important architectural principles and technological rules to ensure the highest availability of any cloud services. These principles and rules have implications during all design processes and decisions. Flexibility, high availability, scalability, security, and performance of the cloud services are all mainly realized by eliminating single points of failure, design for component failures and maintenance of individual components.

 

Cloud values and Manifesto

In a reference to the Agile Manifesto, we formulated our ‘Cloud Manifesto’:

We are uncovering better ways of developing software defined cloud architectures, by doing it and helping others do it.

Through this work we have come to value (amongst others):

 

  • Smaller components over Larger components
  • Redundant components over Singular components
  • Software solutions over Hardware solutions
  • Open source solutions over Proprietary solutions
  • Scaling out over Scaling up
  • Orchestration over Management
  • Keeping up with modern solutions over Holding on to known but dated solutions

 

That is, while there is definitely value in the items on the right, we value the items on the left more.

 

Deviating from these architectural principles and values, is off course possible due to very compelling business reasons. But before you do that, we explicitly advise you to do analyse the impact of those deviations and whether it really provides you with more business value.

 

Building Blocks

One of the implications of our cloud principles and values is that we use building blocks on different levels of the infrastructure, ranging from very generic to detailed and specific building blocks.

 

At the highest level, these architectural building blocks represent functional components like cloud services, hardware components and software components. On lower levels they represent technical building blocks, such as clusters, pools, nodes and OSD’s. We combine these building blocks through defining their relationships, to comprise a stable environment.

 

Not abiding as main cause of failure

It is our experience that negative experiences with open infrastructures are mainly caused by deviation of these cloud architectural principles, values or their technical implications. Do you recognize and appreciate our technical design values or are your values the other way around? Do you want to know if your platform abides to this cloud architecture? Let us know and keep an eye on this blog as I will talk about these principles in the future in more detail.

We are hiring!
Are you our new