Architecting a Modern Digital Platform With Open-Source Software
Architecting a Modern Digital Platform With Open-Source Software
Here's everything you need to know about modern platforms and open-source software.
Join the DZone community and get the full member experience.Join For Free
The digital business landscape is helping businesses to grow beyond geographical boundaries. Transforming your business into a digital business is no longer an optional thing, rather it has become a necessity. Early adopters, late boomers, methodical players, every enterprise is trying to modernize its enterprise IT ecosystem to improve the efficiency and become a leader in their respective enterprise domain. If you are an enterprise architect who is responsible for building a digital platform from scratch, modernize an existing IT platform or lift and shift an existing deployment into the cloud, there are hundreds of different software and technology vendors available to support your effort. The days of proprietary software is long gone and people are more and more migrating towards open-source software (OSS). One of the major challenges of adopting OSS is the maintenance overhead. But that challenge is absorbed by the mega-cloud vendors as well as other cloud services offered by the vendors who created these OSS IP.
In this post, I'm going to discuss building a modern digital platform with OSS. Most of the software components I'm using here are free to download and play around. If you really need to build a production-grade system, it is recommended to get commercial support from the respective vendors. The other important aspect of this architecture is that it is vendor-neutral. You can replace any vendor with OSS or proprietary software without impacting the overall architecture. The components are loosely coupled and can deploy and run independently.
The core design principles of this architecture are
- Loose coupling
- Standard interfaces
- Agile development
- Open Source Software
- Modularity and replaceability
- Computing efficiency
If you are familiar with the enterprise architecture, the aforementioned design principles are not new for you. Those are concepts we have been discussing the day in day out within enterprise architecture panels. Let's understand them at a higher level.
Loose coupling between components allows each and individual component to growing themselves without worrying about other components or without distracting the overall system behavior. If the components are coupled together, every change you made will become a change in the dependent component and it can have a riffling effect on the entire system.
Standard interfaces allow you to interact with many different channels without modifying a single line of code. As an example, if you expose your business services through REST/HTTP interface, multiple consumer channels like web, mobile, and partner systems can interact with that pretty easily.
Agile development is about how frequently you are able to release a given feature while maintaining the overall quality of the system. In a typical enterprise, it is taking weeks to months to years to roll out a project which has taken those enterprises back. But with the agile development, new features can be implemented end to end within hours to days and rollout into production systems with high quality.
Resiliency is a key concept in modern enterprise systems because the components are distributed across various hosts and mostly connected over the network. The network can go down or degrade at any given time and that should not put the entire system into a blackout stage. Instead, these intermittent failures need to be absorbed by the components and they should be designed in a manner to withstand those failures.
Open-Source Software (OSS) is becoming the de-facto way of building software systems in the enterprise because of the many advantages it offers over proprietary software. Some of them include:
- Modularity, loose coupling, standard interfaces, and open-source software allows you to build a system that can be replaced at any given time without worrying about the user experience. As an example, you could replace an API Management vendor within a month if you built your APIs with standard definitions like OAS 3.0 or Swagger 2.0 without many customizations.
- Replaceability is also critical when designing a platform for the next 5-10 years because vendors can go in different directions within this longer time duration.
- Computing efficiency, or resource efficiency, is critical when it comes to building this kind of platforms since they do not bring the ROI immediately. So rather than overspending on resources, having a flexible yet scalable deployment model allows the business leaders to justify their decisions on building digital platforms to the highest level people like CEOs.
The reality check though is that not all these factors were possible to adopt in the past because of the technical limitations. But with the emerging OSS solutions, almost all of these design principles can be adopted with proper architecture and design.
It is absolutely not possible to finish an enterprise architecture discussion without mentioning the words "microservices," "containers," and "agility." Because of that fact, and for good reason, the architecture we are going to design adheres to microservices standards and will be deployed in containers with agility at its core.
Figure 01: Modernized Digital Platform Architecture
The above architecture diagram captures multiple dimensions. From left to right, it captures the user interaction flow of the architecture along with functional components (modules) within the architecture. All these components are interacting with each other through standard interfaces and removing one component would not black-out the overall system. From top to bottom, it captures the layers of modules and their relative position in terms of deployment. Let's try to understand each layer in detail.
This is the component layer which is already running in your enterprise. You may have installed Commercial Off The Shelf (COTS) systems, Software as a Service (SaaS) solutions, SQL/No-SQL databases, various Message Brokers as well as some other in house tools which you have built. The characteristics of these systems are not fully compatible with the design principles which we need to adhere to. But these systems play an integral part within the enterprise IT system which is not easy to replace. Even though some systems like in house tools can be replaced with new services, the rest of the components will stay for a longer period of time. Instead of trying to replace that layer or re-architect that, we will make sure that these systems interoperate with our modern architecture in a seamless manner. When building interoperability, we can choose 2 options.
- Direct connectivity - If these systems expose standard interfaces like HTTP, the modern application layer can directly connect with this layer
- Anti-Corruption Layer - If the interfaces are non-standard (e.g. SAP, FIX, ISO8583, etc.), an intermediate component like ESB can be used to connect with this layer
This layer can utilize some of the cross-functional capabilities like governance, monitoring/analytics and security.
This is the section of architecture which we build from scratch and will be the layer where most of the modern design principles are applied. The core business services can be implemented as microservices which are capable of
- Develop/debug/test independently
- Deploy independently
- Scale independently
- Automated deployment through CI/CD
- Running on containers
- Loosely coupled
These microservices development can be done with agile practices and through small teams which will work on a given task end to end from designing, implementing to testing.
Once the core business services are implemented as microservices, these services need to be exposed to consumers through a managed interface. This is where API Management comes into the picture. The core business services cannot be exposed as it is to the end customer since those business use cases might require information from multiple core microservices. This requires additional processing at the enterprise back end which can be implemented as a set of separate microservices called "integration microservices". At the end of the day, these services are similar to microservices but the actual implementations are mainly around common integration requirements like
These set of microservices are more aligned with the requirements of the end-users and their applications. These services sometimes connect to legacy services layer as well through the anti-corruption layer or directly if it is a standard interface.
Once these core business services and integration microservices are implemented, these services need to be monitored, governed and secured using centralized, cross-functional components. These services can be exposed to consumers through a set of micro gateways so that one set of microservices does not affect the performance or availability of another set of microservices. These micro gateways provide common functionalities which are required by the microservices layer. Here are some of the functionalities provided by Micro Gateway.
This API microgateway can run along with each microservice as a sidecar or it can run multiple APIs for a selected set of microservices which are required for a given application or use case.
When there are 100s of microservices implemented, it becomes a real challenge to manage these microservices. That is where the service mesh comes to the rescue. Service mesh data plane controls the traffic flow between microservices and integration microservices while the control plane controls the overall configuration of the data plane interactions and apply various QOS policies and collect telemetry data.
When building a digital platform with a modern approach like microservices, it is essential to have a proper governing layer due to the number of different technologies used and the amount of autonomy each time posses. As depicted in the above architecture, there can be 100s of different services implemented by autonomous teams with different SLAs, technologies, message formats, etc. Having a central governance platform to keep all the details about these services will be a key when this platform expands with more and more new services. Some of the features expected of the governance layer are mentioned below:
- Lifecycle Management (LCM)
Run-time governance and design time governance are two critical facets of the governance requirements. Design-time governance incorporates most of the aforementioned requirements while run-time governance capabilities are mostly covered through the underlying infrastructure and orchestration layers.
Monitoring and analytics are two separate requirements, which are interconnected. Having proper monitoring on the application layer is essential when adopting a microservices architecture. Most of the early adopters of microservices architecture highlight the importance of monitoring when it comes to management and maintenance of the platform. When something goes wrong within a given service, tracking down the issue (debugging) to a particular microservice will become a tedious task if there is no proper monitoring and tracing in place. Monitoring the platform is two-fold.
- Monitoring computing resources — CPU/Memory/Threads/GC
- Monitoring Applications — TPS, Response time, Availability, Usage, Tracing
Sometimes passive monitoring is not sufficient to become a leader in the respective industry or domain. Analyzing business operations in real-time and taking actions is critical in competing with peers. Analytics capabilities are typically divided into three categories.
- Batch analytics — Information is analyzed over a long period of time by running batch jobs on a stored data
- Real-time analytics — Analyze information in real-time and taking decisions immediately and sending alerts/notifications
- Machine learning/ Predictive analytics — Proactively analyze and predict events before they occur and plan business operations accordingly (e.g. plan the autoscale groups for seasonal traffic increase)
Protecting business services is a critical requirement of any digital platform. Data is money. So protecting your data is like protecting your money. There are two main functionalities required out of the security layer.
- Authentication — Verify the identity of the user who is trying to access business data
- Authorization — Verify the authority of the user to access a given resource or service
Protecting microservices and micro-integration services is enforced at the microgateway layer where it can interact with a security provider to validate the user requests. OAuth2 and JWT are two popular technologies used to protect microservices.
Another key aspect of building a modern digital platform is the continuous integration and continuous deployment or CI/CD. It plays a pivotal role in building an agile digital platform, which is capable of doing multiple releases within a day to compete in the market. It allows enterprises to gain the below-mentioned advantages.
Exposing the protected services to the external world can be done with the usage of a load balancer. Even though this becomes a single point of failure, by having multiple instances of the load balancer, users can get rid of that failure. At this layer, additional security measures can be taken to protect malicious users from attacking the system (DOS attacks).
Once the services are developed, selecting an infrastructure to run these services plays a major role in the overall system design and architecture. Microservices are destined to be run on a container platform like Docker. But running on a container platform does not guarantee the other demands of the consumers. That is where a container orchestration platform comes into the picture. It provides the capabilities mentioned below.
- Service discovery
- Overlaying network and DNS
- Ingress controller to accept external traffic
- Automated rollouts and rollbacks
The aforementioned capabilities are key to build the modern application layer with 100s of services running with different workloads and SLAs while utilizing the same set of computing resources.
Container run-time is the core piece of software that made all these modern architectures possible. It provided an efficient mechanism to run multiple workloads on a single computing resource without sacrificing resources to run an entire operating system (guest OS). Container run-time platform hides the complexity of resource allocations within a computer similar to the way an operating system handles it but without needing an OS. It also provides the below-mentioned advantages.
At the bottom of the stack, it is the actual hardware which is going to run your software. Containers can run on any infrastructure from physical machines to virtual machines to Infrastructure as a Service (IaaS) providers. Depending on the workload, users can select the type of infrastructure that needs to be used.
The above architecture is an open architecture that can be implemented with many different technologies for the same component. Let's see how this architecture can be built using a 100 percent open-source software stack.
The below architecture diagram depicts the open-source software that can be used for each and every component.
Figure 02: Modern enterprise digital platform with OSS
Let's see how each open-source technology is selected for relevant components within the architecture.
- Infrastructure layer — OpenStack is an open-source IaaS software that you can use to build a virtualization layer on top of your on-premise data center resources.
- Container runtime — Docker is the most adopted container runtime used in the industry for enterprise deployments.
- Container orchestration — Kubernetes is becoming the de-facto standard for container orchestration. Most of the IaaS providers offer managed Docker services, which will offload the entire management aspect of the Kubernetes deployment.
- Microservices implementation — Spring Boot is the most popular open-source framework written in Java for microservices development. There are many other open-source frameworks for other languages like Go, .Net, etc.
- Service Mesh framework — Istio is becoming the industry-adopted service mesh technology, not because of the backing by tech giants but due to its performance and stability.
- Integration microservices — Ballerina is becoming the language of choice when it comes to writing integrations in a microservices style of architecture.
- Governance — WSO2 API Manager is an open-source API management platform that provides design-time governance for your microservices architecture.
- Monitoring/Analytics — Prometheus is an open-source monitoring framework that is capable of monitoring complex architectures like MSA. Grafana is an open-source platform for beautiful analytics and monitoring.
- Security — WSO2 Identity Server is an open-source identity and access management platform capable of providing authentication and authorization capabilities to the architecture.
- Micro gateway — WSO2 API Microgateway is an open-source gateway built for supporting microservices architectures where users need to run gateways for a selected set of APIs and with private jet mode.
- Load balancer/Ingress controller — Nginx is one of the leading software load balancers, which has an implementation of ingress controller for Kubernetes-based deployments.
- Anti-Corruption Layer — Apache Camel is one of the most popular ESB solutions that is widely accepted.
- DevOps and Automation — GitHub can be used as the source repository that maintains the source code developed. Jenkins can be configured to automate the build, test, and deployment process, which will do frequent releases without any human interaction. Ansible is used to manage the infrastructure and automate server deployment.
The architecture which was initially described is not restricted to the technologies which are mentioned above. There are many open-source software alternatives you can find in the industry that does the exact same thing, so choose wisely from these vendors. Here is a list of alternative OSS vendors.
- Infrastructure layer — Apache Cloudstack
- Container runtime — Rkt
- Container orchestration — Docker swarm, Mesos DCOS, Pivotal Cloud Foundry
- Microservices implementation — MSF4J, DropWizard, Gokit, Vert.X
- Service Mesh framework — Linkerd
- Integration microservices — Spring Integration, Apache Camel-K
- Governance — Traefik, WSO2 Governance Registry
- Monitoring/Analytics — ELK stack, WSO2 Stream Processor.
- Security — Forgerock
- Micro gateway — Kong
- Load balancer/Ingress controller — Kong
- Anti-Corruption Layer — WSO2 Enterprise Integrator
- DevOps and Automation — GitLab can be used as the source repository that maintains the source code. TravisCI can be configured to automate the build, test, deployment process which will do frequent releases without any human interaction. Chef or puppet is used to manage the infrastructure and automate the server deployment.
Published at DZone with permission of Chanaka Fernando , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.