Simplify DevOps with Microservices and Mobile Backends.pptx

Editor's Notes

• #3: Hi, I’m Mark Nelson, an architect and developer evangelist. I lead a team that builds, owns, sells, and supports a backend platform that simplifies building and deploying Spring Boot applications and unifies web and mobile development, with the power of the Oracle Database. Thanks for joining us today.
• #4: Many developers build microservices and mobile applications, and they need a highly scalable backend to run them on. In this session we’ll talk about an exciting new developer preview from Oracle that provides the ability to run a backend "as a service" for these applications. This new approach lets developers focus on writing their application--providing simple APIs to access a scalable, reliable, secure backend with all the features modern applications need. Modern apps use containers, Kubernetes, and microservices. We’ll discuss the 12 proven patterns for microservices success, and how the backend platform brings them together in an integrated stack. The patterns include things like Transactions and data consistency across microservices (called Sagas), Data refactoring, bounded contexts, Event Mesh, and more. I hope some of you in the audience today use Spring Boot and/or are mobile developers, if so, you’ll find the backend simplifies your DevOps and DataOps. We have a hands on lab available here today, or anytime online, that will guide you through using the backend to build a Cloud Banking application from scratch. We’d love to hear from you, I’ll share our email addresses so you can tell us what you think.
• #5: There are three key parts to a modern application backend stack – containers, Kubernetes and of course, the database. There is a separate presentation here at Level Up today about running the Oracle Database in containers, and the Oracle Database Operator for Kubernetes that makes the Oracle Database Kubernetes native - so I won’t cover those topics in depth. If you can’t make it to those sessions, don’t worry - they will be available on-demand after the event is finished. The converged Oracle Database is available on Cloud, Cloud-at-customer and on-prem. It’s a horizontally scalable, sharded global database, that supports all modern data types and workloads, with a Transaction Manager and Event Mesh for Microservices built-in. We’ll get into this detail a bit later. A unifying theme here is that the Oracle Database is ready for the modern app dev stack that uses Postgres, Kafka, MongoDB, Snowflake as point solutions for operations and analytics. Let’s now dive into the Backend integration.
• #7: So let’s talk about the backend platform…
• #8: Backend as a Service is an important pattern, that is hugely popular in the mobile app dev space, but relatively rare for microservices. It allows developers to focus on the frontend or business logic and consume backend services without needing to build or maintain them. It’s a perfect fit for cloud and containers, and it allows us to build reliable, scalable, fault tolerant applications.
• #10: Why do we want a multi-cloud backend platform? Developer’s roles are evolving to focus less on DevOps and operations and more on the business logic, and we’re developing against higher level APIs – we are consuming services instead of worrying about configuring infrastructure. The traditional DBAs are becoming more adept with application runtimes and DevOps. And databases are taking on more, with built-in microservices support like Event Mesh, with both streaming data and batch data for DataOps or data engineering.
• #11: So why Spring Boot? Well, we looked at a lot of data, from a wide range of researchers. We looked at things like job advertisement, stack overflow trends, GitHub repositories, Google search trends, and so on. And the message that comes through clearly is that Spring Boot and the Spring Framework are by far the most popular, not by a little bit, but orders of magnitude. And we think it’s largely because you can write less code, get more done, and there’s a huge amount of knowledge and support and a very active community.
• #12: But we wanted to include mobile developers too. We think that microservices and mobile are better together. Mobile developers tend to rely on backend as a service, front end frameworks and tools are quite different to the server side, and mobile developers want to focus on the app. They don’t care about boring backend stuff like tables and indexes, and what kind of CPU to use. They care about easy to use APIs that provide the services their apps need to get the job done. Parse – super easy to use, APIs and SDKs for all the platforms. Talk about 23c JSON Duality Views
• #13: I mentioned earlier that we have observed 12 patterns for microservices success.
• #14: We all know that most IT projects fail, and microservices projects are no different. By now, it is well established that microservices do not provide a silver bullet, they are not suitable for every project, and they trade one form of complexity for another. But we have also seen enough projects using microservices to be able to identify patterns that lead to success, and we will look at some examples of these patterns in this session. Kubernetes has also emerged as the dominant deployment platform for microservices applications. It provides a lot of capabilities and of course it comes with its own complexities. Over the last few years, we have also added a whole host of features to the Converged Oracle Database to make it the perfect choice for microservices – from pluggable database containers and support for a wide range of data types and workloads, to transactional event queueing and streaming, and features like Saga support.
• #15: The Backend as a Service approach is the single most important of the 12 patterns for microservices that separates success from failure. It brings together all the other patterns and realizes them in a scalable deployment that is easy to use and provides a range of platform services for applications to use – services like authentication, identity, event streaming, monitoring, tracing, deployment, CI/CD, and so on.
• #16: So, let’s talk about the Oracle Backend for Spring Boot.
• #17: We have a Developer Preview available right now on OCI Marketplace, in fact we have four releases already, and we are doing a new release every month. The platform gives you an Oracle Autonomous Database and an OKE cluster (that’s Oracle Container Engine for Kubernetes). In that cluster we pre-install and pre-configure a whole stack of services that Spring Boot applications need – service registry, config server, workflow, API Gateway, vault, and a Transaction Manager – we’ll talk more about that one later! And the observability tools you need to monitor and manage your applications, identify problems, drill down to find causes, and trace user requests all the way from their entry at the API Gateway through to database and queueing operations that get performed. The Backend for Spring Boot is built on OCI, and we take advantage of a lot of OCI services like (ADB OKE, etc) Best performance and lowest cost on OCI We also provide an on-prem install option today, and we have an Azure option coming really soon.
• #18: We have rich development environment support too, including a CLI and Visual Studio extension, Spring Boot Starters for Oracle technologies, and support for all the most popular Spring Boot modules, with more coming in every release.
• #19: In addition to that, the platform provides mobile app backed service like documents, file, external config, authentication, geolocation and spatial, push notifications, caching on local (on-device) storage. We have APIs and SDKs across all popular languages and frameworks including both the Apple and Android ecosystems, web frameworks like React and Flutter, as well as REST and GraphQL APIs.
• #20: Of course all of this is designed to support the 12 patterns. Did you know that Oracle Database has provide application containers for years now – we call them “pluggable databases” – to the user it looks like they have a whole database to themselves, but you can run as many of these containers as you like all on a set of shared infrastructure. Each one is isolated from the others, you can’t break out from your container to the host database. And you can easily move these containers from one host to another. Does this sound like anything else you are familiar with? Containers right? The ones we run our microservices inside of in Kubernetes. Spring Boot applications running in containers in Kubernetes, each with its own database container – a perfect implementation of the “database per service” pattern, or “bounded contexts” if you prefer, without the need to manage, maintain, patch, scale hundreds of individual pieces of database server infrastructure.
• #22: In fact, we’ve added a lot of capability to the converged Oracle Database over the last few releases, specifically for microservices – and we have even more coming in 23c later this year. Let me highlight just six of those. We have direct support for the saga pattern in the database, transactional event queues and event mesh, including support for the transactional outbox pattern, we have open telemetry and Prometheus collectors for metrics and tracing, we have a tool that will let you analyze actual usage of objects in a monolithic database and help you identify clusters that can be used to refactor that database into bounded contexts. We have Spring Boot Starters and SDKs for Relational Data, Streaming, JSON Documents, Graph, and more coming all the time. And not many people know this, but you can even run microservices directly in the database with instant startup and scale to zero, using popular languages like Java and JavaScript.
• #27: Once our service is deployed, we can use the included tools to monitor and diagnose issues. Here you see an example of the Spring Boot dashboard in Grafana. The information you see here is being collected by Prometheus from the Spring Actuator that we added to our service earlier. Notice in the pull down that it discovers all the services and we can choose which we want to look at. There is a lot of data here about resource usage, and JVM, database and HTTP statistics. We can use this dashboard to identify problems. For example, suppose we see that the response time for our service suddenly gets about 100 times slower for about a minute. What could be causing that?
• #28: We can use the Jaeger web UI to drill down into specific service invocations during that minute to see what was going on. In this trace we can see that the fraud service was taking a lot longer than it normally does. It looks like the delay is occurring even before it tries to connect to the database – now we can go and investigate logs and code and work out what was happening. Maybe the database ran out of available connections? Maybe someone was running a resource hogging query? We can investigate further using the Oracle Autonomous Database system monitoring tools to find the root cause of this issue and work out how to avoid it reoccurring in the future.
• #29: Of course, not all our services will just read or write data in the database. Sometimes we need to interact with events or messages too. If we wanted to use Oracle Transactional Event Queues – the high-performance, low latency transactional event streaming built into the Oracle Database – we can easily add the Oracle Spring Boot Starter for TxEventQ to our Maven Project POM file, as you see here, and then provide the connection details in our Spring Boot application properties file – or put them into the Spring Config Server so they can be injected to the service.
• #30: Once we have done that, the starter will automatically inject both a JDBC connection and a JMS connection factory into our service for us. We can use Spring JMS to easily access queues and topics using standard Spring annotations like this one that configures this method to receive messages from the queue called “mailbox”.
• #31: Let’s take a moment to talk about transactions
• #32: One of the key challenges with microservices architecture in general, and the database per service pattern in particular is how to handle data consistency. There are lots of ways to do this of course, and some are more work than others. It really comes down to whether or not a business application can tolerate inconsistency and for how long. For some applications, having inconsistent data for some period is not that big a problem, but for most applications it is just not an option. Some approaches take developers away from their real work to make sure data is reconciled, or forces them to write complex logic to detect and handle issues. A better approach is to use a transaction manager – that’s not a new idea - we’ve been doing that for literally decades now. But today, with the proliferation of microservices its just way more important.
• #33: The backend includes Oracle Transaction Manager for Microservices, which enables developer to use distributed transactions to ensure data consistency across services. It supports all three big models that we see in common use today – XA, Long Running Actions and Try-Confirm/Cancel.
• #34: It has libraries for all the popular languages as well as REST APIs. Its deployed into Kubernetes right alongside your services, and it works with all the common transaction managers, including, of course, the Oracle Database and Tuxedo.
• #35: Let’s wrap up this section of the talk. I’ve told you a bit about how our unified backend for mobile and web apps plus Kubernetes and the Oracle Database make app dev simple, help you avoid cloud lock-in, and let developers focus on their frontends and business logic. We have a Developer Preview available today, that you can play with, and we’d love to hear your thoughts about it. It’s important we know your interest, so we can evolve this platform for your needs. We’d love to get more input from customers who are using Spring Boot, and would like to get more web and mobile apps convergence. Please consider sending us an email today, let us know the company you work for, how you use Spring Boot and/or your mobile app dev approach, so we can follow up with you.
• #36: If you’d like to know more, you can try out the platform right here today in a Hands-on Lab after lunch – or if you are watching this later, the very same Live Lab is available online anytime.
• #37: In Hands-on Lab 5 – you will learn how to deploy the platform, build Spring Boot microservices from scratch, deploy them into the platform, implement the saga pattern using Long Running Actions to manage data consistency across microservices and you will extend the mobile app to add a new “Cloud Cash” feature that would allow users to send cash to anyone instantly.
• #38: The Lab is based on a “CloudBank” sample application, which is made up of a number of Spring Boot microservices which use the platform services we’ve talked about today, like the service registry, the API Gateway, the transaction manager, and so on. The mobile app is written in Flutter, which is a really exciting new up-and-coming framework for building apps for any screen from a single code base.
• #39: Just like in a real bank, most of the “origination” applications – things like opening a new account, applying for a credit card, or buying an insurance policy - are implemented outside of the core transactional banking applications. The Cloud Cash feature that you will implement touches both worlds.
• #41: We’d love you to try out everything we’ve talked about today – and to make that easy for you, we offer free sample code, free trials of Oracle cloud, a permanent free tier, a free developer version of the Oracle Database, and hundreds and hundreds of hours of free training on our LiveLabs platform.
• #43: Reach out to Sanjay or me at our emails. We look forward to hearing from you.