In the post “The Business Case Justification for PaaS” we looked at the benefits and a business case for PaaS and the post “Developing a PaaS Migration Strategy” outlined ways to migrate applications to PaaS. In this blog we will look at the steps to create a reference architecture and developer best practices to get the most benefits from your platform.
As cloud infrastructure service providers continue to add platform services to their offerings and pure-play PaaS vendors grow their market share, the available options to build applications has exploded. Companies that do not have any guidelines on the use of cloud computing face the risk of cloud sprawl, where the proliferation of cloud instances, services and service providers grow out of control.
Most companies cannot operate as unicorn startup companies and are constrained by budget, regulations and compliance concerns, and available talent to build their applications. Picking the right services for your application should include considerations for price, scalability, availability, manageability, security and compliance. There are hundreds of services available from a single cloud provider with new services added at a staggering pace. Application developers need architecture guidance on the best services to use for their solutions to control cost, deliver faster and ensure compliance.
The pure-play PaaS model is said to be “opinionated” giving the developer everything they need to build applications within the constraints of the platform. This approach inherently limits the number of options available to developers to build applications, which works well as long as the application domains are limited – e.g. 12-factor apps. But going outside of the application domains supported by the platform, for example IoT, could prove to be problematic and require additional services.
The first step to define PaaS architecture guidelines is to define your application domains (types of applications) and the services used to build each domain. Domain specific application scenarios include 12-factor web app, microservices, big data / batch / analytics, IoT, etc… Then for each domain define a specific reference architecture to build an application within that domain. Also, a deployable reference implementation is extremely helpful. The ability for a development team to quickly provision their environment and build a new application is highly beneficial and will speed the adoption of PaaS.
The reference architecture should define and diagram the CI/CD pipeline to build and deploy the application, the PaaS services and configurations used in the solution, utilities for cross cutting concerns like monitoring, and guidance on capacity and sizing. The reference architecture should also define and document required security and compliance details, which can greatly speed the delivery of applications in a regulated environment.
For applications that fall outside of well-defined domains it is helpful to define a catalog of services recommended to build applications.
A service catalog is a curated list of services that are approved and compliant within the enterprise, for example within the following categories:
- Compute and Networking
- Storage, cache, content management and delivery services
- Database and analytics services
- Security and identity management services
- Application services – AI, mobile, IoT, etc.
- Application tools and management services – control, monitor, test, deploy
- Environment management services – monitor, control, build
The service catalog should be categorized and include attributes for price, scalability, availability, manageability, and security. Company specific attributes such as compliance, projects where used, contacts for SMEs can also be added.
Some cloud service providers offer a service catalog via a marketplace or application tiles and the ability to customize the services available to developers. This is an appealing developer user experience for consuming services and helps with adoption especially if the ability to provision services is automated.
Finally, it is helpful to provide developers guidelines, patterns and standards on building and deploying their applications.
These standards should be lightweight with a focus on developer experience and Agility. For example, the following guidelines would be helpful for the 12-factor web app and microservices domains:
Native Cloud Development Guidelines
- 12 Factor App guidelines – customized to the PaaS environment
- Language and framework standards – e.g. Spring Boot
- PaaS – technology specific best practices e.g. AWS, Azure, GCP, PCF, Kubernetes Docker and OpenShift
- Security implementation guidelines, network, scan automation, patch
- DevOps – provision, deploy, CI/CD guidelines
- Runtime standards – service mesh, application performance monitoring, logging
- Migration guidance – when, why and how to migrate legacy monoliths
Microservices Architecture (MSA)
- MSA reference architecture for containers and application services
- Development standards and guidelines
- Domain Driven Design
- API Standards
- DevOps tools and guidelines
- Integration standards and patterns – APIs and events
Perficient has teams of highly experienced cloud strategists, architects, DevOps and change management experts should you need any help with your cloud architecture and implementation. We have invested in developing cloud reference architecture and training experienced individuals on the latest development approaches including native cloud development, PaaS, DevOps, microservices and re-platforming.
