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

Microservices or Functions? Use Both with Red Hat OpenShift

Microservices or Functions? Use Both with Red Hat OpenShift

The key to modern application development is delivering value quickly while keeping development and operations costs under control. Often, this balance involves a trade-off between focusing on experimentation and dealing with unpredictable loads (where functions shine) or focusing on predictable performance and operation costs (where microservices are a better answer). The immediate answer to this is mix-and-match approach, but that can’t happen by naively combining disjointed technologies and platforms.

In this session, we'll demonstrate how the Kubernetes ecosystem, and in particular, Red Hat OpenShift, allows you to use both microservices and functions cohesively by taking advantage of the underlying platform and layering technologies, such as Istio and Knative, on top of it. This session will introduce the technologies and compare and contrast microservices and functions, pointing out which use cases are best served by each and providing developers with practical guidance and demos on how to take advantage of both in their applications.

Ee7ff5474c7ecfe0ec209df0eeb531fa?s=128

Marius Bogoevici

May 08, 2019
Tweet

Transcript

  1. Microservices or Functions? Use both with Red Hat OpenShift Marius

    Bogoevici Principal Specialist Solution Architect May 8, 2019
  2. Marius Bogoevici • Principal Specialist Solutions Architect at Red Hat

    ◦ Specialize in Integration/Messaging/Data Streaming • OSS contributor since 2008 ◦ Spring Integration ◦ JBoss ecosystem ◦ Spring XD, Spring Integration Kafka ◦ Former Spring Cloud Stream project lead • Co-author “Spring Integration in Action”, Manning, 2012
  3. Unfortunately, we cannot predict the future. As an organization, we

    must be able to observe and experiment in our environments and react accordingly. We need to be agile.
  4. On the other hand we must be mindful of our

    resources; We want to eliminate waste, reduce time to experiment, and make it cheap so we can increase our returns.
  5. We cannot build complex systems from complex parts. We must

    keep our components as simple and understandable as possible.
  6. WHY MICROSERVICES? WHY FUNCTIONS Monolith Microservices Operational efficiency Fast value

    delivery
  7. MICROSERVICES AND CONTAINERS

  8. • Reduce the responsibility of a service to a specific

    business functionality • Allow parallelization of development work • Independently deployable (infra) and independently releasable (business) • Can optimize for increased utilization (separating out parts of the code base that exhibit different i/o, throughput, latency needs) • Re-use services where applicable Microservices
  9. • Microservices great at enabling agility from existing systems •

    Well understood business, well understood boundaries • Don’t optimize for microservices unless you have problems with your application architecture • Don’t complicate experimentation/value discovery with complex architecture What’s your use case?
  10. Containers and microservices

  11. • Use a platform that makes running apps reliable, transparent

    and boring • In-built resource management ◦ Memory, CPU, disk • Elastic scaling • Monitoring and failover ◦ Health, logging, metrics • Routing and load balancing • Rolling upgrades and CI/CD • Namespacing Orchestrating containers on cloud native platforms
  12. WHAT ABOUT FUNCTIONS?

  13. • Usually when logic not well understood • MVPs are

    throwaway • Usage patterns unknown • Adoption unpredictable Exploratory use cases
  14. • Low number of hours/minutes of use • Event-driven, spikey

    utilization • Lots of compute for very short period of time Under-utilization use cases
  15. • Webhook callbacks • Scheduled tasks • File processing •

    Reacting to database changes • Limited stream processing Limited integration use cases
  16. • Use a platform that makes running apps reliable, transparent

    and boring • In-built resource management ◦ Memory, CPU, disk • Elastic scaling • Monitoring and failover ◦ Health, logging, metrics • Routing and load balancing • Rolling upgrades and CI/CD • Namespacing Orchestrating containers on cloud native platforms
  17. • Pay only for usage without regard for topology (Serverless)

    • Event driven by nature • On demand • Write only code, heavy lifting is handled for you • High parallelization • High utilization Functions as a Service (FaaS)
  18. The meaning of serverless: FaaS vs autoscaling?

  19. • Microservices: request-reply and event-driven • Containers (on prem, in

    the cloud) • Functions • Serverless (databases, message queues, caches, etc) As you move to cloud native, you have options
  20. Container orchestration creates a level playing field for these options

    at different levels of abstraction
  21. DEMO

  22. What’s the business use case?

  23. Utilization?

  24. Two deployment strategies

  25. Container orchestration creates a level playing field for these options

    at different levels of abstraction
  26. Your technology radar • Service Mesh (e.g. Istio): ◦ Provide

    microservice interconnectivity • Serverless platforms (e.g. Knative) ◦ Container build and on-demand scheduling • Container-native frameworks (e.g. Quarkus) ◦ Optimize Java workloads for containerized apps • FaaS frameworks (e.g. Camel-K) ◦ Schedule integration code directly on platform
  27. None