microservice   2438

« earlier    

Home | OpenFaaS - Serverless Functions Made Simple
Serverless Functions Made Simple for Docker and Kubernetes.
serverless  microservice  kubernetes  lambda  devops 
yesterday by paule
The Twelve-Factor App
A methodology for building modern, scalable, maintainable software-as-a-service apps.
devops  bestpractice  microservice 
yesterday by paule
Building a Microservices Ecosystem with Kafka Streams and KSQL
Excellent. Includes kafka transactions, and blocking HTTP requests. The bit about websockets, that when order is placed we need to lookup the websocket host that initiated the order (if any), is interesting.

"Systems built in this way, in the real world, come in a variety of guises. They can be fine-grained and fast executing, completing in the context of an HTTP request, or complex and long-running, manipulating the stream of events that map a whole company’s business workflow. This post focusses on the former, building up a real-world example of a simple order management system that executes within the context of an HTTP request, and is entirely built with Kafka Streams. Each service is a small function, with well-defined inputs and outputs. As we build this ecosystem up, we will encounter problems such as blending streams and tables, reading our own writes, and managing consistency in a distributed and asynchronous environment."

"In distributed architectures like microservices, this problem is often more pronounced as data is spread throughout the entire estate. Each service becomes dependent on the worst case performance and liveness of all the services it connects to. Caching provides a respite from this, but caching has issues of its own: invalidation, consistency, not knowing what data isn’t cached, etc."

"So instead of pushing the data problem down a layer, stream processors are proudly stateful. They let data be physically materialized wherever it is needed, throughout the ecosystem. This increases performance. It also increases autonomy. No remote calls are needed!"

"Using an event-streaming approach, we can materialize the data locally via the Kafka Streams API. We define a query for the data in our grid: “select * from orders, payments, customers where…” and Kafka Streams executes it, stores it locally, keeps it up to date. This ensures highly available should the worst happen and your service fails unexpectedly (this approach is discussed in more detail here)."

"But what if you’re not running on the JVM, or you want to do stateful stream processing in a separate process (say, to keep your application logic stateless)? In this case, you’d use KSQL. KSQL provides a simple, interactive SQL interface for stream processing and can be run standalone and controlled remotely. KSQL utilizes the Kafka Streams API under the hood, meaning we can use it to do the same kind of declarative slicing and dicing we might do in JVM code using the Streams API. Then a native Kafka client, in whatever language our service is built in, can process the manipulated streams one message at a time. Whichever approach we take, these tools let us model business operations in an asynchronous, non-blocking, and coordination-free manner."

"Finally, it’s also possible to control a stream processor running in a separate process using KSQL. This creates a hybrid pattern where your application logic can be kept stateless, separated from your stream processing layer, in much the same way that you might separate state from business logic using a traditional database."

"Note also that the Orders Service is partitioned over three nodes, so GET requests must be routed to the correct node to get a certain key. This is handled automatically using the Interactive Queries functionality in Kafka Streams, although the example has to implement code to expose the HTTP endpoint. (Alternatively, we could also implement this view with an external database, via Kafka Connect.)

The example also includes code for a blocking HTTP GET so that clients have the option of reading their own writes (i.e. avoiding the race conditions that come with eventual consistency). In this way we bridge the synchronous, blocking paradigm of a Restful interface with the asynchronous, non-blocking processing performed server-side:"

"The architecture described here is more complex than many simple CRUD systems. That’s to say the baseline cost is higher, both in complexity and in latency. This tradeoff is worth making if the system we are building needs to grow and evolve significantly in the future. Notably, incorporating different teams, as well as offline services that do not require a response go immediately back to the user: re-pricing, fulfillment, shipping, billing, notifications, etc. In these larger, distributed ecosystems, the pluggability, extensibility, and decoupling that comes with the event-driven, brokered approach increasingly pay dividends as the ecosystem grows. "

"I think that the only way to handle it is to keep global cache which maps all connections (clientID – serverID – OrderKey) and then every server instance could use this table to figure out where a websocket is attached to. Then redirect the output to the correct instance.
Of course there are disconnect/connect , failures , etc. scenarios – but the idea is the same
Will be interesting to hear your opinion"

"I think that the only way to handle it is to keep global cache which maps all connections (clientID – serverID – OrderKey) and then every server instance could use this table to figure out where a websocket is attached to. Then redirect the output to the correct instance.
Of course there are disconnect/connect , failures , etc. scenarios – but the idea is the same
Will be interesting to hear your opinion"
DistributedSystems  AsyncUI  Kafka  KafkaStreams  streaming  KSQL  microservice  messaging 
2 days ago by colin.jack
kafka-streams-examples/src/main/java/io/confluent/examples/streams/microservices at 4.0.0-post · confluentinc/kafka-streams-examples
"The Orders Service also includes a blocking HTTP GET so that clients can read their own writes. In this way we bridge the synchronous, blocking paradigm of a Restful interface with the asynchronous, non-blocking processing performed server-side."
eventsourcing  streaming  kafka  microservice  DistributedSystems  WebSockets  AsyncUI 
2 days ago by colin.jack
Build Services on a Backbone of Events | Confluent for Microservices
Excellent. Great diagram showing event driven approach to placing an order.

"There are three advantages of this ‘Query by Event-Carried State Transfer’ approach:

* Better decoupling: Queries are local. They involve no cross-context calls. This ties services far less tightly than their request-driven brethren.
* Better autonomy: The Orders service has a private copy of the Stock dataset so it can do whatever it likes with it, rather than being limited to the query functionality offered by the Stock Service.
* Efficient Joins: If we were to “look up the stock” on every order, we would effectively be doing a join over the network between the two services. As workloads grow, or more sources need to be combined, this can be increasingly arduous. ‘Query by Event Carried State Transfer’ solves this issue by bringing queries (and joins) local.

This approach isn’t without its downsides though. Services become inherently stateful. They need to keep track of, and curate, the propagated data set over time. The duplication of state can also make some problems harder to reason about (how do we decrement the stock count atomically?) and we should be careful of divergence over time. But all these issues have workable solutions, they just need a little consideration. This is well worth the effort for larger, more complex estates. "

"*A bounded context, here, is a set of services which share the same deployment cycle or domain model."

"To limit the scope of remote queries we can use a clustered context pattern. Here event flows are the sole communication pattern between contexts. But services within a context leverage both event-driven processing and request-driven views, where they are needed."

"In the code example here, the ID is used to tie the two together. So you write an Order with ID=5. If you immediately send a read request for ID=5, if it doesn’t exist in the view, the view will block until order 5 is available or the call times out. This assumes orders have unique ids (or ids are versioned)."

"You shouldn’t have to use individual consumer groups. So long as you key the request by a request ID or correlation ID then the response will come back to the same node that sent it (with all nodes in the same consumer group) – so you shouldn’t need a distributed cache, local one is fine. If there is a rebalance for any reason you could get timeouts but that’s usually fine.

Note the use of the KStreams metastore to reroute requests to their key owner:

"The schema registry provides details of what events are published on what topics. Confluent will be releasing a better UI for this in the future which includes the ability to search schemas etc. But the best way to manage schemas today is actually in github. This provies a repo of available event schemas, you can propose changes to those events and have your downstream consumers +1 them. Consumers can also propose PRs for things they need."

"Decoupling: Break long chains of blocking commands. Decompose synchronous workflows. Brokers decouple services so it’s easier to plug new ones in, or change those that are there.
Offline/Async flows: When the user clicks a button many things happen. Some synchronously, some asynchronously. Design for the latter and the former falls out for free.
State Transfer: event become the dataset of your system. Streams provide an efficient mechanism for distributing datasets, so they can be reconstituted, and queried, inside a bounded context.
Joins: It’s easier to combine/join/augment datasets from different services. Joins are fast and local.
Traceability: It’s easier to debug the distributed ‘murder mystery’ when there’s a central, immutable, retentive narrative journaling each interaction as it unfolds in time."
eventsourcing  streaming  kafka  microservice  DistributedSystems  WebSockets  AsyncUI  CQRS  EventCarriedStateTransfer  boundedcontext  read_your_own_writes 
2 days ago by colin.jack
What Lies Between: The Challenges of Operationalizing Microservices
Colin Breck presents practical approaches to take microservices into production or increase the value provided by existing systems. Breck explores how to integrate microservices at scale, including asset management, security considerations, and representing uncertainty in data. Breck examines approaches that can be used to debug, monitor, adapt, and control microservices.
microservice  observability 
10 days ago by jessedavis

« earlier    

related tags

aws  8  abstract  acid  admin  administration  android  api  app  approach  architecture  arquitecture  article  asyncui  authentication  authorization  aws  azure  backend  base  bestpractice  book  boundedcontext  build  choreography  cleancode  client  clientside  cloud  cms  code  composition  computing  conference  consistency  consistent  container  contrib  convention  convergence  cookpad  course  cqrs  dashboard  data  ddd  decouple  decoupling  deeplink  deployment  design  dev  development  devops  distributed  distributedsystems  documentation  dojo  dotnetcore  driven  drupal  drupal8  edge  endpoint  engine  entities  entity  envoy  ephermal  event-driven-architecture  event  eventcarriedstatetransfer  eventsourcing  evolution  example  external  featuretoggle  floss  framework  from-github  gcp  generator  github  go  gokit  golang  graalvm  graceful  graphql  grpc  guide  hacking  hn  host  howto  http  important  integration  interoperability  issue  java  june  jwt  k8s  kafka  kafkastreams  klang  ksql  kubernetes  lambda  later  learn  learning  library  limit  logging  lumen  mesh  message  messaging  micro_services  microcontroller  microfrontend  micronaut  microserviceoriented  microservices  microsoft  mock  mocking  modular  modularization  module  monitoring  monolith_to_microservices  monolithic  mountebank  nanodegree  networking  nginx  nodejs  observability  oop  opensource  operation  opinion  orchestration  pattern  patterns  php  pipeline  processing  programming  proto  protobuf  protocol  proxy  read_your_own_writes  reference  repository  res  routing  rpc  saga  sample  scheduler  schema  security  server  serverless  service  servicemesh  serviceoriented  shopify  shutdown  single  slice  soa  software  spark  spring  stiching  stranglerpattern  stream  streaming  style  sysadm  sysadmin  systemdesign  talks  technicaldecisionmaking  testing  tool  toread  tracing  traefik  train  training  tutorial  type:presentation  uber  udacity  unclebob  vertical  vertx  viktor  web-development  web  webapplication  webdev  websockets  worker  workflow 

Copy this bookmark: