31 Matching Annotations
  1. Jul 2023
  2. Jan 2023
    1. Deploy engines as separate app instances and have them only communicate over network boundaries. This is something we’re starting to do more.

      Before moving to this microservice approach, it's important to consider whether the benefits are worth the extra overhead. Jumping to microservices prematurely is something I've seen happen more than once in my career, and it often leads to a lot of rework.

  3. Nov 2022
    1. As I think today microservice can do much more than just gives predictions using a single model, like:

      List of differences between a microservice and inference service.

      (see bullet points below annotation)

  4. Oct 2022
    1. Python is known for using more memory than more optimized languages and, in this case, it uses 7 times more than PostgresML.
    2. PostgresML outperforms traditional Python microservices by a factor of 8 in local tests and by a factor of 40 on AWS EC2.
  5. Sep 2022
    1. In fact, if you are familiar with applying the CQRS model, even without data reconstruction, you can achieve a certain degree of data decoupling. Even if it is used in a non-microservice architecture application, CQRS can still benefit you a lot.

      CQRS pattern, regardless of being microservices or not, can benefit you for decoupling the data (to a certain degree) from your application.

  6. Apr 2022
  7. Dec 2021
    1. Artifactory/Nexus/Docker repo was unavailable for a tiny fraction of a second when downloading/uploading packagesThe Jenkins builder randomly got stuck

      Typical random issues when deploying microservices

    2. Microservices can really bring value to the table, but the question is; at what cost? Even though the promises sound really good, you have more moving pieces within your architecture which naturally leads to more failure. What if your messaging system breaks? What if there’s an issue with your K8S cluster? What if Jaeger is down and you can’t trace errors? What if metrics are not coming into Prometheus?

      Microservices have quite many moving parts

    3. If you’re going with a microservice:

      9 things needed for deploying a microservice (listed below)

    4. some of the pros for going microservices

      Pros of microservices (not always all are applicable):

      • Fault isolation
      • Eliminating the technology lock
      • Easier understanding
      • Faster deployment
      • Scalability
  8. Nov 2021
    1. because commonly an API is not intended to handle high performance requirements.

      ... while microservices do (are supposed to "handle large amounts of information ... cannot accept idle services"

  9. Mar 2021
  10. Oct 2020
  11. 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.
  12. 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

  13. Jul 2019
  14. 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)

  15. Feb 2019
  16. 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.
  17. Dec 2017