This post gives a quick summary on the similarities and differences of the terms SysAdmins, DevOps, Platform engineering and after that it dives deeper into how Microsoft answers the requests for Internal Developer Platforms.
The way we create and deploy applications has changed a lot. A decade ago developers made monolithic applications and would ask the SysAdmins to deploy a physical/virtual machine to land their application on.
Even the SysAdmins would have different expertise such as Virtualization, Storage, or Networking and if you were lucky the stars aligned and they would be all available to execute your request in a timely manner. Only if the budget holder approved of course.
When the cloud era started, many of these technology silos could be avoided by developers. The cloud brought a new operating model and cloud providers delivered a self-service model with it, that enabled them to deploy the infrastructure themselves to host their application.
The term ‘DevOps’ was brought to the stage as the operational part was taken away by the traditional SysAdmin and the developers became responsible for that part as well. Some developers were fine with that approach, others rather only kept themselves busy with developing instead of the deployment methods and managing underlying infrastructure.
Platform engineering is the upcoming term for the practice of building a platform that is specifically end for making developer’ lives easier. It’s not build specifically by DevOps engineers, developers or SysAdmins but ‘Platform engineers’.
The ultimate goal of Platform engineering is providing developers the best experience and productivity by providing self-service capabilities with automated infrastructure operations. Depending on the platform of choosing the actual work that needs to be done on the platform differs. Some platforms offer a turn-key approach while with other you’d still need to get your hands dirty and install Kubernetes (for example).
Platform engineers provide an integrated product most often referred to as an “Internal Developer Platform” covering the operational necessities of the entire lifecycle of an application. Depending on the chosen platform it can support those developers still in the traditional application development, developers dipping their toes in containerization, or cloud-native developers.
Keep an eye out for the supportability of the platforms by the vendors, depending on the level you expect from your platform you can mix and match your solution. If you want to deliver PaaS services to your internal organization and make use of an open-source PaaS solution, it is harder to get support when it breaks then when using a fully integrated PaaS platform.
Microsoft’s efforts in providing an answer dates back to 2013 where the predecessor of Azure Pack was launched, which is the predecessor of the current Microsoft Azure Stack portfolio. Microsoft Azure Stack HCI provides a platform that enables IaaS and PaaS capabilities on any physical location. The IaaS and PaaS services are the same services that you are used to and consuming when using Microsoft Azure and provide the same functionality. As the platform is connected with Microsoft Azure using Azure Arc, we make use of the management layer of Microsoft Azure to manage and interact with the platform and the services on top. That also means that the platform and services, which can run anywhere, are visible and manageable the same way from the Azure Portal or CLI as PaaS services running in a Microsoft datacenter. The fully integrated cloud approach of the platform satisfies the requirements for an Internal Developer Platform; “providing developers the best experience and productivity by providing self-service capabilities with automated infrastructure operations”.
Developers can develop their applications as they always have done, Azure Stack HCI provides full self-service capabilities through Microsoft Azure’s API layer which supports Infrastructure as Code (IAC). Developers can create pipelines with the same underlying code, the deployment destination is just a parameter in the deployment. Because of the integration with Azure, you can also benefit of all other features that Microsoft has developed for Microsoft Azure, for example Role-Based Access Control (RBAC) based on Azure Active Directory or security analytics using Microsoft Sentinel.
By using Azure Stack HCI you’re bringing a piece of the Microsoft cloud to your own location, including cloud services.
Microsoft Azure services available for Azure Stack HCI include;
In summary, Azure Stack HCI is an ideal fit for platform engineering because it provides a flexible, scalable, and powerful platform for building and deploying hybrid cloud solutions that can support a wide range of workloads and use cases.
Learn more about Azure Stack HCI and what services are available here or get in touch!