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.

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