The purpose of this pattern is to establish a facade or adapter layer between distinct subsystems that have different data models or communication protocols. The layer acts as a mediator and converts requests made by one subsystem into a format that can be understood by another subsystem. This pattern is useful in ensuring that an application’s design is not restricted by its reliance on external subsystems.
Cloud Adoption Patterns
In my work as a contract Cloud Architect, I’ve seen a good number of customers attempting to move key application workloads to the cloud from a number of different types of environments (on-premise, colo…) over the past 10+ years. Many of those customers struggle, even fail — however, some succeed, why?
How do the successful customers get there faster?
In this article I’ll describe the top six patterns to successful enterprise cloud adoption that I’ve observed in my consulting work. To start, let’s consider two categories that are of utmost importance in building solutions on the public cloud — people and technology. I observe that getting the People focus right is more often done inadequately, so I’ll start with this topic.
People
Software is built by people. Failing to honestly access the capabilities of the current technical team to build using best practice cloud patterns has driven many a project off the rails. ‘Just winging it’ is costly at best, too often, I’ve seen it result in complete project failures.
Assessment of team abilities isn’t enough though. Customers who succeed do three things in the area of People.
- Build applications that solve end-user problems
- Create a culture of learning for both the technical teams and the end-users
- Are led by technical managers
End-Users Focus
In order to build applications that end users actually need, technical teams should be talking with those users on a regular basis. A caution is that Slack, email, and video meetings are a poor substitute for understanding user needs.
The most effective way to gain insight is by actually working together.
The best performing cloud IT teams work side-by-side with end users on a regular basis so that they can deeply understand what to build for their users.
Also, end-users need to understand not only what they will need to do to use new applications, but, importantly, why they are being asked to change the way they work. In the case of my work, bioinformatics, a simple, ‘we are literally out of file storage…
Design and implementation patterns: Part 1
CQRS is a design pattern that separates an application into two parts, one for handling commands – instructions to change to state of the system and another for handling queries – requests for information about the state of the system.
The main idea behind CQRS is to have separate models for reads and writes. This separation allows for more flexibility in designing and scaling the system, as well as improving performance and maintainability.
The Command model is responsible for handling incoming commands, validating them, and executing them. The commands are typically expressed as immutable messages and are processed asynchronously. The write side is typically optimized for handling high-frequency, low-latency operations.
The Query model is responsible for handling queries, fetching data from one or more read-only data stores, and returning the results. The read side is optimized for handling high-volume, low-latency operations.
- Allows independent scaling of read and write workloads.
- Easier scaling, optimizations, and architectural changes.
- Closer to business logic with loose coupling.
- The application can avoid complex joins when querying.
- Clear boundaries between the system behavior.
- More complex application design.
- Message failures or duplicate messages can occur.
- Dealing with eventual consistency is a challenge.
- Increased system maintenance efforts.
Compute Resource Consolidation (CRC) pattern
This pattern focuses on consolidating multiple tasks or operations of the system into a single computational unit. It is oftentimes used in cloud computing environments and helps improve efficiency, increase utilization and reduce costs.
For example, assume there is a cloud platform that provides virtual private servers to their customers for web hostings. Each web site is hosted on a dedicated VPS resulting in a large number of virtual machines running on in the system. If the resource utilization is not optimized then the system will incur high costs for maintaining and managing all those virtual machines.
- Can helps minimizing the number of physical resources and lower the management costs.
- Having a reduced number of resources makes it easier to add/remove capacity based on demand.
- Can helps gaining higher resource utilization rates.
- Contributes reducing overall management complexity by simplify tasks such as monitoring, provisioning, and maintenance.
- Enhance the performance of the system – workloads benefit from higher physical resources such as CPU, memory, and storage.
- Consolidating multiple tasks into a single unit can be time-consuming and complex. It requires meticulous planning, testing, and execution to ensure a smooth migration.
- It may lead to dependencies between different workloads. As a result, failure of a consolidated environment can affect multiple workloads at the same time.
- If workloads are not managed properly, some resource-intensive workloads may impact the performance of others that share the same resources.
- The level of resource isolation between workloads might get reduced. If a workload experiences issues, for example security breaches, it may impact other workloads.
Sidecar pattern
The Sidecar pattern complements and enhances the existing main service. By deploying a separate and independent service, it offers supplementary functionalities like network services, monitoring, configuration, logging, and more. It operates alongside the main service and provides additional functionality without directly affecting the main service’s codebase.
- Can be attached as a separate process within the same host or sub-container of the primary application.
- Operates independently from the primary application in terms of the runtime environment and programming language.
- There is minimal latency when exchanging information between main and sidecar services.
- Accesses the same resources as the primary application. As an example, it can monitor system resources that are utilized by both the sidecar and the primary application.
- Introducing a sidecar service adds an extra layer of complexity to the overall system architecture.
- The sidecar pattern often involves inter-process communication between the main service and the sidecar which may add some network communication overhead.
- When multiple services share a common sidecar, maintaining synchronization and consistency across all services can become challenging.
- Deploying and managing multiple services (main service and sidecar) can be more complex than deploying a single service.
