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.

Marius Bogoevici

May 08, 2019
Tweet

More Decks by Marius Bogoevici

Other Decks in Technology

Transcript

  1. Microservices or Functions?
    Use both with Red Hat OpenShift
    Marius Bogoevici
    Principal Specialist Solution Architect
    May 8, 2019

    View full-size slide

  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

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  5. We cannot build complex systems from complex parts.
    We must keep our components as simple and
    understandable as possible.

    View full-size slide

  6. WHY MICROSERVICES? WHY FUNCTIONS
    Monolith Microservices
    Operational efficiency Fast value delivery

    View full-size slide

  7. MICROSERVICES AND CONTAINERS

    View full-size slide

  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

    View full-size slide

  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?

    View full-size slide

  10. Containers and microservices

    View full-size slide

  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

    View full-size slide

  12. WHAT ABOUT FUNCTIONS?

    View full-size slide

  13. ● Usually when logic not well understood
    ● MVPs are throwaway
    ● Usage patterns unknown
    ● Adoption unpredictable
    Exploratory use cases

    View full-size slide

  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

    View full-size slide

  15. ● Webhook callbacks
    ● Scheduled tasks
    ● File processing
    ● Reacting to database changes
    ● Limited stream processing
    Limited integration use cases

    View full-size slide

  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

    View full-size slide

  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)

    View full-size slide

  18. The meaning of serverless:
    FaaS vs autoscaling?

    View full-size slide

  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

    View full-size slide

  20. Container orchestration creates a level
    playing field for these options at different
    levels of abstraction

    View full-size slide

  21. What’s the business use case?

    View full-size slide

  22. Utilization?

    View full-size slide

  23. Two deployment strategies

    View full-size slide

  24. Container orchestration creates a level
    playing field for these options at different
    levels of abstraction

    View full-size slide

  25. 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

    View full-size slide