Skip to content

Introduction. Microservice Architecture. From Java EE To Cloud Native. Openshift VS Kubernetes

  1. Introduction
  2. Platform Reference Architecture
  3. Solution Architect. IT Architecture Frameworks
  4. Pets vs Cattle Analogy
  5. Service-Oriented Arhitecture vs Event-Driven Architecture
  6. Cloud Native
  7. Technical Debt
  8. Twelve-Factor Apps in Kubernetes
  9. Event Driven Architecture EDA
  10. Understanding the Differences Between Event-Driven, Message-Driven, and Microservices Architectures
  11. Multi-Tenancy Architecture
  12. Architecture Decision Records
  13. Self service developer platform
  14. Shift-Left
  15. Disaster Recovery
  16. SaaS
  17. Multi Cloud
  18. Cloud Automation
    1. Automation Glossary
  19. Microservices Best Practices and Design Patterns
  20. Microservice Patterns
    1. CQRS Pattern
  21. Microservices Anti Patterns
  22. Micro Frontend Architecture. Microservices for the Frontend
  23. Backends for Frontends
  24. Data Engineering
  25. Cloud Migration Checklist
  26. Microservices Failures
  27. Top Microservices Frameworks
  28. Transform Legacy Java Apps to Microservices with automation tools
  29. Namespaces for Data Structuring
  30. From SysAdmin to Architect
  31. Raft Consensus Algorithm
  32. PaaS
  33. Modular Monolith
  34. From Java EE To Cloud Native
  35. Monolith to Microservices Using the Strangler Pattern
  36. Microservices to Monolith
  37. Openshift VS Kubernetes
  38. Career Path
  39. Full Stack Developer’s Roadmap
  40. Software Development Models
  41. Domain Driven Design DDD
  42. Software Development Tools
  43. vFunction. A system to transform monolithic Java applications into microservices
  44. Software in Automotive Industry
  45. Data Centers in Spain
  46. Bunch of Images
  47. Videos
  48. Devel Videos
  49. Tweets

Introduction

Platform Reference Architecture

Solution Architect. IT Architecture Frameworks

Pets vs Cattle Analogy

  • cloudscaling.com: The History of Pets vs Cattle and How to Use the Analogy Properly
    • In the old way of doing things, we treat our servers like pets, for example Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot, and replaced on the line.
    • Pets: Servers or server pairs that are treated as indispensable or unique systems that can never be down. Typically they are manually built, managed, and “hand fed”. Examples include mainframes, solitary servers, HA loadbalancers/firewalls (active/active or active/passive), database systems designed as master/slave (active/passive), and so on.
    • Cattle: Arrays of more than two servers, that are built using automated tools, and are designed for failure, where no one, two, or even three servers are irreplaceable. Typically, during failure events no human intervention is required as the array exhibits attributes of “routing around failures” by restarting failed servers or replicating data through strategies like triple replication or erasure coding. Examples include web server arrays, multi-master datastores such as Cassandra clusters, multiple racks of gear put together in clusters, and just about anything that is load-balanced and multi-master.
  • traefik.io: Pets vs. Cattle: The Future of Kubernetes in 2022

Service-Oriented Arhitecture vs Event-Driven Architecture

Cloud Native

Technical Debt

Twelve-Factor Apps in Kubernetes

Event Driven Architecture EDA

Understanding the Differences Between Event-Driven, Message-Driven, and Microservices Architectures

Multi-Tenancy Architecture

Architecture Decision Records

Self service developer platform

Shift-Left

Disaster Recovery

SaaS

Multi Cloud

Cloud Automation

Automation Glossary

Microservices Best Practices and Design Patterns

Microservice Patterns

CQRS Pattern

Microservices Anti Patterns

Micro Frontend Architecture. Microservices for the Frontend

Backends for Frontends

Data Engineering

Cloud Migration Checklist

Microservices Failures

Top Microservices Frameworks

Transform Legacy Java Apps to Microservices with automation tools

Namespaces for Data Structuring

From SysAdmin to Architect

Raft Consensus Algorithm

  • The Raft Consensus Algorithm 🌟 etcd is a “distributed reliable key-value store for the most critical data of a distributed system”. It uses the Raft consensus algorithm which was designed to be easy to understand, to scale, and to operate. The protocol and the etcd implementation were very quickly adopted by large distributed systems like Kubernetes, large distributed databases or messaging frameworks, where consensus and strong consistency is a must.

PaaS

Modular Monolith

From Java EE To Cloud Native

Monolith to Microservices Using the Strangler Pattern

Microservices to Monolith

Openshift VS Kubernetes

Career Path

Full Stack Developer’s Roadmap

Software Development Models

Domain Driven Design DDD

  • dzone: The Concept of Domain-Driven Design Explained In this article, we define the core concepts around domain-driven design, explain them, and highlight the advantages and downsides of the approach.
    • Using microservices means creating applications from loosely coupling services. The application consists of several small services, each representing a separate business goal. They can be developed and easily maintained individually, after what they are joint in a complex application.
    • Microservices is an architecture design model with a specific bounded context, configuration, and dependencies. These result from the architectural principles of the domain-driven design and DevOps. Domain-driven design is the idea of solving problems of the organization through code.
    • The business goal is important to the business users, with a clear interface and functions. This way, the microservice can run independently from other microservices. Moreover, the team can also work on it independently, which is, in fact, the point of the microservice architecture.
    • Many developers claim microservices have made them more efficient. This is due to the ability to work in small teams. This allows them to develop different small parts that will later be merged as a large app.
    • They spend less time coordinating with other developers and more time on developing the actual code. Eventually, this creates more value for the end-user.
  • medium.com/codex: DDD — Events Are Complex Why do Events matter so much in Domain-Driven Design?

Software Development Tools

vFunction. A system to transform monolithic Java applications into microservices

Software in Automotive Industry

Data Centers in Spain

Bunch of Images

Click to expand!

microservices infographic

you dont need kubenetes

sw consumers

Openshift SaaS VS Kubernetes SaaS

Openshift VS Kubernetes

Kubernetes on its own is not enough

how mature is your microservices architecture

bytebytego microservice tech stack

Videos

Click to expand!

Devel Videos

Click to expand!

Tweets

Click to expand!