Technology blog

  Context You are developing a server-side enterprise application. It must support a variety of different clients including desktop browsers, mobile browsers and native mobile applications. The application might also expose an API for 3rd parties to consume. It might also integrate with other applications via either web services or a message broker. The application handles requests (HTTP requests and messages) by executing business logic; accessing a database; exchanging messages with other systems; and returning a HTML/JSON/XML response. There are logical components corresponding to different functional areas of the application. Problem What’s the application’s deployment architecture? Forces There is a team of developers working on the application New team members must quickly become productive The application must be easy to understand and modify You want to practice continuous deployment of the application You must run multiple instances of the application on multiple machines ...

  Context You have applied the  Microservices architecture pattern  and the  Database per service pattern . As a result, it is no longer straightforward to implement queries that join data from multiple services. Also, if you have applied the  Event sourcing pattern  then the data is no longer easily queried. Problem How to implement a query that retrieves data from multiple services in a microservice architecture? Solution Define a view database, which is a read-only replica that is designed to support that query. The application keeps the replica up to data by subscribing to  Domain events  published by the service that own the data. Examples My book’s FTGO example application has the  Order History Service , which implements this pattern. There are  several Eventuate-based example applications  that illustrate how to use this pattern. Resulting context This pattern has the following benefits: Supports multiple denormalized views ...

Let’s imagine you are developing an online store application using the   Microservice architecture pattern . Most services need to persist data in some kind of database. For example, the   Order Service   stores information about orders and the   Customer Service   stores information about customers. Problem What’s the database architecture in a microservices application? Forces Services must be loosely coupled so that they can be developed, deployed and scaled independently Some business transactions must enforce invariants that span multiple services. For example, the  Place Order  use case must verify that a new Order will not exceed the customer’s credit limit. Other business transactions, must update data owned by multiple services. Some business transactions need to query data that is owned by multiple services. For example, the  View Available Credit  use must query the Customer to find the  creditLimit  and Orders to calcula...

Domain-driven design  ( DDD ) is a  software design  approach  focusing on modelling software to match a  domain  according to input from that domain's experts. In terms of  object-oriented programming  it means that the structure and language of software code (class names,  class methods ,  class variables ) should match the  business domain . For example, if a software processes loan applications, it might have classes like LoanApplication and Customer, and methods such as AcceptOffer and Withdraw Domain-driven design is predicated on the following goals: placing the project's primary focus on the core  domain  and domain logic; basing complex designs on a model of the domain; initiating a creative collaboration between technical and  domain experts  to iteratively refine a conceptual model that addresses particular domain problems. Criticisms of domain-driven design argue that developers must typically impleme...

  Autoscalling On the CaaS-CNP, you can use the Horizontal Pod Autoscalling (HPA) on your deployment. This automatically scales the number of pods based on observed CPU utilization (or on custom metrics support) The Horizontal Pod Autoscaler is implemented as a Kubernetes API resource and a controller. The resource determines the behavior of the controller. The controller periodically adjusts the number of replicas in a replication controller or deployment to match the observed average CPU utilization to the target specified by user. . apiVersion : autoscaling/v1 kind : HorizontalPodAutoscaler metadata : name : <my-hpa> namespace : <my-namespace> spec : scaleTargetRef : apiVersion : apps/v1 kind : Deployment name : <my-deployment> minReplicas : 2 maxReplicas : 6 targetCPUUtilizationPercentage : 50 $ kubectl apply -f hpa.yaml -n <my-namespace> $ kubectl get hpa -n <my-namespace> Now generate load on your ser...