Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservice architecture, a programming languages perspective

Microservice architecture, a programming languages perspective

Microservice architectures have taken over the industry, and with the rise of cluster schedulers and serverless the envelope is being pushed even further. However while tools like microservices, containers, and schedulers were designed to solve problems associated with the systems of old, they introduce many others like API migrations, service dependencies, and deployment automation. In this talk we will explore these new challenges and see how curiously, these system-level concerns can be tackled with some inspiration from the programming languages community, viewing the world of microservices through the lens of type systems and language runtimes.

Adelbert Chang

July 15, 2019
Tweet

More Decks by Adelbert Chang

Other Decks in Programming

Transcript

  1. val average : float -> float -> float average "hello"

    "curryon" Error: This expression has type string but an expression was expected of type float
  2. What we need Language runtime Deployment service Creating an object

    Deploying a service Reference tracking Service dependencies
  3. What we need Language runtime Deployment service Creating an object

    Deploying a service Reference tracking Service dependencies Garbage collection Deprecating legacy services
  4. What we need Language runtime Deployment service Creating an object

    Deploying a service Reference tracking Service dependencies Garbage collection Deprecating legacy services Type safety Schema checking and evolution
  5. syntax = "proto3"; message Person { string name = 1;

    uint32 age = 2; } protoc --java_out=./java --python_out=./python person.proto
  6. syntax = "proto3"; message Person { string name = 1;

    uint32 age = 2; } public static final class Person extends com.google.protobuf.GeneratedMessageV3 implements // @@protoc_insertion_point(message_implements:Person) PersonOrBuilder { protoc --java_out=./java --python_out=./python person.proto
  7. syntax = "proto3"; message Person { string name = 1;

    uint32 age = 2; } public static final class Person extends com.google.protobuf.GeneratedMessageV3 implements // @@protoc_insertion_point(message_implements:Person) PersonOrBuilder { Person = _reflection.GeneratedProtocolMessageType( 'Person', (_message.Message,), dict( DESCRIPTOR = _PERSON, __module__ = 'person_pb2' # @@protoc_insertion_point(class_scope:Person) )) _sym_db.RegisterMessage(Person) protoc --java_out=./java --python_out=./python person.proto
  8. Compatibility type Changes allowed Upgrade first Schema evolution Taken from

    https://docs.confluent.io/current/schema-registry/avro.html
  9. Compatibility type Changes allowed Upgrade first Backwards • Delete fields

    • Add optional fields Consumers Schema evolution Taken from https://docs.confluent.io/current/schema-registry/avro.html
  10. Compatibility type Changes allowed Upgrade first Backwards • Delete fields

    • Add optional fields Consumers Forwards • Add fields • Delete optional fields Producers Schema evolution Taken from https://docs.confluent.io/current/schema-registry/avro.html
  11. Compatibility type Changes allowed Upgrade first Backwards • Delete fields

    • Add optional fields Consumers Forwards • Add fields • Delete optional fields Producers Full • Modify optional fields Any Schema evolution Taken from https://docs.confluent.io/current/schema-registry/avro.html
  12. Related work • Nelson https://getnelson.io/ • Unison http://unisonweb.org/posts/ • Lasp

    https://lasp-lang.readme.io/ • Partisan http://partisan.cloud/ • Orleans https://dotnet.github.io/orleans/
  13. EOF