I keep track of what is happening in modern data stack, machine learning and cloud native. This series is focused on cloud native.
Microservices and software architecture
Architecture
Introduces main components in cloud native: microservices, container, DevOps, CI/CD. Generally I think CI/CD is part of DevOps, so I added Cloud section.
Whether you are cloud native or not, you are writing software. This article talks about modern application development practice called clean architecture, focusing on decoupling components, reusability, extensibility, testability of software system for constantly-changing requirements. From most inner/core to outer/external, components are:
Entities/Domain model: enterprise business logic, it will only depend other entities. It holds data (state) and logic reusable for various applications. Examples are: User (holds user name, hashed&salted password; logic like validate user name, hash plain-text password); Balance (holds user dependency, amount, limits, logic like verify if given transfer amount is OK)
Use cases: application logic, e.g. authenticate user (based on user-name/password input, validate it and pull user entity from backend); view balance (based on user entity input, pull balance entity from backend); transfer funds (based on user entity and amount input, pull balance entity, verify if transfer permitted, perform if so or report error if not)
Controllers/Interface Adapters: this layer adapts input into a form that’s most usable by the use cases and entities layers. It also formats output from the entities or use cases into a form that’s most suitable for external-facing channels, like translator between inner and outer circles
Framework and Drivers: presentation layer like databases, API, web frameworks, devices.
The author has a golang implementation of clean architecture of API finding users.
Entities layer: user domain model
Use Cases layer: define application logic of input port (handling data from the outer layer and defined as abstract) and output port (handling data from Use cases to the outer layer and defined as abstract)
Interface Adapter layer: handles API requests that come from the outer layer, and prepares user data to view
Frameworks and Drivers layer: the actual database instance is injected here
Typical cloud-native application has following characteristics: Twelve-Factor Application, microservices, containers, backing services like data stores, message brokers, monitoring, and identity services, automation including Infrastructure as Code, CI/CD-based deployments, enabling reliability, scalability, faster releases, cost reduction, no vendor lock-in.
Microservices and API management
Typical features of service mesh
Lots of cross-cutting features are needed by microservice. Without a service mesh layer, the logic regulating communication may be built into each service; but, as communication becomes more sophisticated, a service mesh becomes increasingly beneficial.
Traffic management: traffic split/mirror, request routing, request timeout/retry, circuit breaking, load balancing, blue/green deployment, canary deployment
Security: in-transit data encryption (TLS termination), identity and certificate management/secure naming, authentication, authorization
Control: policies (rate limit)
Observability: logging, monitoring, distributed tracing, mesh visualization
API management vs. service mesh: API management is typically adopted for REST services that face external developers — referred to as north-south traffic; service mesh is more commonly used by internal suites of microservices to help control lateral, or east-west, communication.
Container
General container
Kubernetes best practice: correct Labels and Selectors, Health Checks, don’t use default namespace, don’t use ‘Latest’ Tag, monitoring and logging, correct service port mapping, avoid Crashloopbackoff error
7 design principles for containers
- single concern: a container usually manages a single process, and most of the time that single process addresses a single concern
- high observability: at the minimum, container should have health checks — liveness and readiness; application should log important events into the standard error (STDERR) and standard output (STDOUT) so log aggregation tools like Fluentd and Logstash can pick up (which can integrate with tracing and metrics-gathering libraries such as OpenTracing, Prometheus, etc.)
- lifecycle conformance: application needs to handle events from the platform, some most important events are: SIGTERM, SIGKILL, like in article 1, 2, other events are PostStart and PreStop
- image immutability: container image should not change between different environments, for tracking and auto-rollback, which implies the use of an external means of storing the runtime data and relying on externalized configurations that vary across environments, rather than creating or modifying containers per environment.
- process disposability: container needs to be as ephemeral as possible and can be replaced by another container instance at any point in time. This means that containerized applications must keep their state externalized or distributed and redundant. It also means the application should be quick in starting up and shutting down, and even be ready for a sudden, complete hardware failure
- self-containment: a container should contain everything it needs at build time. Only exceptions are things such as configurations, which vary between different environments and must be provided at runtime. For example, a containerized web application may also require a database container. This principle does not suggest merging both containers, but instead, at runtime, the web application container will access the database container as needed.
- runtime confinement: every container declare its resource requirements and pass that information to the platform, and stay confined to the indicated resource requirements, e.g. resource profile of a container in terms of CPU, memory, networking, disk influence on how the platform performs scheduling, auto-scaling, capacity management
Cloud-specific container technologies
https://codelabs.developers.google.com/codelabs/cloud-run-deploy
The code lab for Google Cloud run: a serverless container technologies. It uses Google cloud build to build container, and use “gcloud run” CLI to deploy container to “cloud run”.
403 Forbidden
Your client does not have permission to get URL from this server.
Code sample and guide to migrate ASP.NET MVC to ASP.NET Core MVC on Google Cloud
DevOps
FinOps
Cost saving factors for S3
Storage: choose storage class according to access pattern. Use Amazon S3 storage class analysis can help determine access pattern and lifecycle rules can move data to cheaper tier, remove noncurrent versions, or use S3 Intelligent tiering (it costs money too).
Other cost factors: requests: API call to save or retrieve a file from S3;
AWS Data Transfer: Transferring data into AWS S3 from the internet is free, but you will pay for most other file transfers. Management and Analytics: storage management features and analytics (Amazon S3 Inventory, S3 Storage Class Analysis, S3 Storage Lens, and S3 Object Tagging); Replication: In addition to the storage and transfer fees for replication, you may also need to pay for S3 Replication Time Control.
Cybersecurity
Design areas:
Application
Data
Device/endpoint
Transport
User/Identity
Infrastructure
Principles:
Never trust, always verify (and treat every user, device, data flow, and workload as untrusted using dynamic security policies and following the least privilege principle).
Assume a breach and operate and defend resources assuming that hackers are already within the environment. In this scenario, you should always deny by default and scrutinize and monitor everything in real-time.
Verify explicitly. Use multiple attributes (both dynamic and static, based on all available data points, including user identity, location, device health, service or workload, data classification, and anomalies) to develop confidence levels for contextual access decisions.
Cloud
The naming of different private access options in Google Cloud are confusing. Private Google access: let VM without external IP connect to Google APIs and services; Private services Access: let VM without external IP connect to specific Google services and third-party services; serverless VPC Access: let Cloud Run, App Engine standard environment, and Cloud Functions to connect to GCP resources, without needing external IPs
Secret management is provided by all 3 major clouds: AWS secret manager, Azure key vault, Google cloud secret manager. They all have integration with their Kubernetes service (GKE, EKS, AKS)
