17 Matching Annotations
  1. Oct 2020
  2. May 2020
    1. Clients are updated to use the new service rather than the monolith endpoint. In the interim, steps such as database replication enable microservices to host their own storage even when transactions are still handled by the monolith. Eventually, all clients are migrated onto the new services. The monolith is "starved" (its services no longer called) until all functionality has been replaced. The combination of serverless and proxies can facilitate much of this migration.
  3. Apr 2020
    1. Good microservice design follows a few simple rules

      Microservice design rules:

      • Be role/operation based, not data centric
      • Always own your data store
      • Communicate on external interfaces or messages
      • What changes together, and is co-dependent, is actually the same thing
      • All services are fault tolerant and survive the outages of their dependencies
    2. What Microservices are supposed to be: Small, independently useful, independently versionable, independently shippable services that execute a specific domain function or operation. What Microservices often are: Brittle, co-dependent, myopic services that act as data access objects over HTTP that often fail in a domino like fashion.

      What Microservices are supposed to be: independent

      VS

      what they often are: dependent

    3. In the mid-90s, “COM+” (Component Services) and SOAP were popular because they reduced the risk of deploying things, by splitting them into small components

      History of Microservices:

      1. Came from COM+ and SOAP in the mid-90s.
      2. Which later led to the popularisation of N-Tier ("split up the data-tier, the business-logic-tier and the presentation-tier"). This worked for some people, but the horizontal slices through a system often required changing every “tier” to finish a full change.
      3. Product vendors got involved and SOAP became complicated and unfashionable, which pushed people towards the "second wave" - Guerrilla SOA. This led to the proliferation of smaller, more nimble services.
      4. The "third wave" of SOA, branded as Microservice architecture is very popular, but often not well understood
    1. central service registry

      discovery of microservices, orchestration

    2. minimizing latency and enabling event-driven interactions with applications.

      async communication, AMQP, advanced message queuing protoal

  4. Jul 2019
  5. May 2019
    1. Tiago Roberto Lammers - Nossa jornada DevOps na Delivery Much para microserviços e o que aprendemos

      Microservices é um dos temas cobertos pela certificação DevOps Tools do Linux Professional Institute e também é um assunto determinante na escolha de ferramentas do cinto de utilidade de um profissional DevOps. Aproveite para conversar com o Tiago sobre a sua experiência com o uso do Docker, assunto que também cai na prova.

      Tópicos (dentre outros):

      701.1 Modern Software Development (weight: 6) 701.4 Continuous Integration and Continuous Delivery (weight: 5) 702.1 Container Usage (weight: 7)

  6. Feb 2019
  7. Nov 2018
    1. One way to identify cycles is to build a dependency graph representing all services in the system and all RPCs exchanged among them. Begin building the graph by putting each service on a node of the graph and drawing directed edges to represent the outgoing RPCs. Once all services are placed in the graph, the existing dependency cycles can be identified using common algorithms such as finding a topological sorting via a depth-first search. If no cycles are found, that means the services' dependencies can be represented by a DAG (directed acyclic graph).
    2. Dependency cycles are most dangerous when they involve the mechanisms used to access and modify a service. The operator knows what steps to take to repair the broken service, but it's impossible to take those steps without the service.
  8. Dec 2017