Java TechTalk "Spring boot made life easier with Kubernetes and Microservices"
Download as PPTX, PDF0 likes475 views
This document provides an overview of using Spring Boot, Kubernetes, and microservices. It discusses the popularity of microservices and their pros and cons. It introduces Domain Driven Design (DDD) and how it differs from a more traditional approach by defining bounded contexts for subdomains. The document then provides a quick introduction to Kubernetes and Spring Boot. It describes a typical microservices architecture with services corresponding to domains and communication via REST APIs. Finally, it mentions a sample project using Spring Boot, Docker, and Minikube.
Java TechTalk "Spring boot made life easier with Kubernetes and Microservices"
- 1. TechTalk "Spring boot made life easier with Kubernetes and Microservices"
- 2. Popularity of the Microservices DDD Introduction to Kubernetes Introduction to Spring Typical architecture Sample project
- 5. Pros and Cons of Microservices ◦ Testing can be very complex ◦ Rapid provision of new versions ◦ Robust monitoring ◦ Dev team became partially devops team in regarding owned microservice ◦ Resilience ◦ Scalability ◦ Ability to use diverse tools and Languages ◦ Faster time to market ◦ More granular maintenance ◦ Operation costs improvement
- 6. Compromises Business wants soft be created cheap, fast and with the good quality, but reality check that only 2 of that requirements is possible to accomplish.
- 9. Not a perfect solution for all cases Every software architecture out there has its drawbacks, and MSA is not an exception. Much of it relates to the hassle of getting used to new ways of doing things. Tasks like testing, deployment, and monitoring are a tad more complex to perform on MSA systems than on monolithic applications. To put this in perspective, the Amazon web application calls 100 to 150 services to get data used for building a web page, Hailo has 160 different services, Netflix has in excess of 600 services. Furthermore, the benefits of decoupling may be overwhelmingly convincing; but it also means duplication of efforts, mitigating fault tolerance and network latency, and handling a bunch of issues that were a lot more implicit in monoliths. None of this is rocket science, but compared to a monolithic application, there is an added layer of complexity. Partitioning an application into microservices isn’t only a science; it is very much an art. And although, rewriting a microservice using newer, more efficient technology later isn’t prohibitive; refactoring the boundary of a microservice (when you find a good reason to, as may happen sometime later thanks to the focus on evolutionary design), say by having to move a responsibility between services, is difficult because of the loose coupling of services.
- 11. DDD definition ◦ Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. The name comes from a 2003 book by Eric Evans that describes the approach through a catalog of patterns. Since then a community of practitioners have further developed the ideas, spawning various other books and training courses. The approach is particularly suited to complex domains, where a lot of often-messy logic needs to be organized.
- 12. Classic way Requirements A company provides IT Body Leasing. They have some Employees, and a lot of Freelancers as Subcontractors. Currently, they use Excel sheets to manage their Customers, Freelancers, Timesheets and so on. The Excel solution does not scale well. It is not multi-user ready and does not provide security and audit logs. So they decided to build a new web-based solution. Here are the core requirements: •A searchable catalog of Freelancer must be provided •The new solution must allow to store the different Communication Channels available to contact a Freelancer •A searchable catalog of Projects must be provided •A searchable catalog of Customers must be provided •The Timesheets for the Freelancers under contract must be maintained Based on these requirements the development team decided to model everything using UML to get a big picture of the new solution. Now let’s see what they did.
- 13. Define sub domains Ok, let’s look at the requirements. We could think that there is a “Body Leasing” Domain, and that is completely right. But if we look deeper into the Domain, we see something that is called “Subdomain”. The following Subdomains might be possible: Identity and Access Management Subdomain Freelancer Management Subdomain Customer Management Subdomain Project Management Subdomain
- 14. DDD way Okay, what happened here? There are now Bounded Contexts for every identified Subdomain. The Bounded Contexts are isolated, they know nothing of each other. They are only glued together by a set of common types, like UserId, ProjectId and CustomerId. In DDD this set of common types is called a “Shared Kernel”. We can also see what is part of the "Core domain" and what is not. If a bounded context is part of the problem we are trying to solve and cannot be replaced by another system, it is part of the "Core domain". If it can be replaced by another system, it is a "Generic Subdomain". The "Identity and access management" context is a "Generic Subdomain", as it could be replaced by an existing IAM solution, such as Active Directory or something else. We applied a set of tactical and strategical patterns to the model. These patterns help us to build a better model, improve fault tolerance and also to increase maintainability. Within each Bounded Context there are Aggregates and Value Objects. Aggregates are object hierarchies, but only the root of the hierarchy is accessible from outside of the Aggregate. Aggregates take care of business invariants. Every access to the object tree must go thru the Aggregate and not over one element within. This greatly increases encapsulation. Aggregates and Entites are things with an unique id in our model. Value Objects are not things, they are values or measures, like a UserId. Value Objects are designed to be immutable, they cannot change their state. Every state changing method returns a new instance of the value Object. This helps us to eliminate unwanted side effects.
- 15. DDD Define services corresponding to Domain- Driven Design (DDD) subdomains. DDD refers to the application’s problem space - the business - as the domain. A domain is consists of multiple subdomains. Each subdomain corresponds to a different part of the business. Subdomains can be classified as follows: •Core - key differentiator for the business and the most valuable part of the application •Supporting - related to what the business does but not a differentiator. These can be implemented in-house or outsourced. •Generic - not specific to the business and are ideally implemented using off the shelf software
- 16. Business capabilities Define services corresponding to business capabilities. A business capability is a concept from business architecture modeling. It is something that a business does in order to generate value. A business capability often corresponds to a business object, e.g. Business capabilities are often organized into a multi-level hierarchy. For example, an enterprise application might have top-level categories such as Product/Service development, Product/Service delivery, Demand generation, etc.
- 17. KUBERNETES Quick intro into kubernetes
- 18. Kubernetes + Docker microservices Actual microservice are actual console applications that hosting inside a containers. Communication between services is typically done by REST API, but can use any tcp and even udp connections.
- 21. SPRING Quick intro into spring
- 22. Spring intro ◦ Spring Framework is a Java platform that provides comprehensive infrastructure support for developing Java applications. Spring handles the infrastructure so you can focus on your application. ◦ The Spring Framework Inversion of Control (IoC) component addresses this concern by providing a formalized means of composing disparate components into a fully working application ready for use. The Spring Framework codifies formalized design patterns as first-class objects that you can integrate into your own application(s).
- 23. Modules Spring Framework consists of features organized into about 20 modules. These modules are grouped into Core Container, Data Access/Integration, Web, AOP (Aspect Oriented Programming), Instrumentation, and Test, as shown in the following diagram.
- 24. Core Modules ◦ The Core Container consists of the Core, Beans, Context, and Expression Language modules. ◦ The Core and Beans modules provide the fundamental parts of the framework, including the IoC and Dependency Injection features. The BeanFactory is a sophisticated implementation of the factory pattern. It removes the need for programmatic singletons and allows you to decouple the configuration and specification of dependencies from your actual program logic. ◦ The Context module builds on the solid base provided by the Core and Beans modules: it is a means to access objects in a framework-style manner that is similar to a JNDI registry. The Context module inherits its features from the Beans module and adds support for internationalization (using, for example, resource bundles), event-propagation, resource-loading, and the transparent creation of contexts by, for example, a servlet container. The Context module also supports Java EE features such as EJB, JMX ,and basic remoting. The ApplicationContext interface is the focal point of the Context module. ◦ The Expression Language module provides a powerful expression language for querying and manipulating an object graph at runtime. It is an extension of the unified expression language (unified EL) as specified in the JSP 2.1 specification. The language supports setting and getting property values, property assignment, method invocation, accessing the context of arrays, collections and indexers, logical and arithmetic operators, named variables, and retrieval of objects by name from Spring's IoC container. It also supports list projection and selection as well as common list aggregations.
- 25. Data Access Modules ◦ The Data Access/Integration layer consists of the JDBC, ORM, OXM, JMS and Transaction modules. ◦ The JDBC module provides a JDBC-abstraction layer that removes the need to do tedious JDBC coding and parsing of database-vendor specific error codes. ◦ The ORM module provides integration layers for popular object-relational mapping APIs, including JPA, JDO, Hibernate, and iBatis. Using the ORM package you can use all of these O/R-mapping frameworks in combination with all of the other features Spring offers, such as the simple declarative transaction management feature mentioned previously. ◦ The OXM module provides an abstraction layer that supports Object/XML mapping implementations for JAXB, Castor, XMLBeans, JiBX and XStream. ◦ The Java Messaging Service (JMS) module contains features for producing and consuming messages. ◦ The Transaction module supports programmatic and declarative transaction management for classes that implement special interfaces and for all your POJOs (plain old Java objects).
- 26. Web Modules ◦ The Web layer consists of the Web, Web-Servlet, Web-Struts, and Web-Portlet modules. ◦ Spring's Web module provides basic web-oriented integration features such as multipart file-upload functionality and the initialization of the IoC container using servlet listeners and a web-oriented application context. It also contains the web- related parts of Spring's remoting support. ◦ The Web-Servlet module contains Spring's model-view-controller (MVC) implementation for web applications. Spring's MVC framework provides a clean separation between domain model code and web forms, and integrates with all the other features of the Spring Framework. ◦ The Web-Struts module contains the support classes for integrating a classic Struts web tier within a Spring application. Note that this support is now deprecated as of Spring 3.0. Consider migrating your application to Struts 2.0 and its Spring integration or to a Spring MVC solution. ◦ The Web-Portlet module provides the MVC implementation to be used in a portlet environment and mirrors the functionality of Web-Servlet module.
- 27. AOP and Instrumentation Modules ◦ Spring's AOP module provides an AOP Alliance-compliant aspect-oriented programming implementation allowing you to define, for example, method-interceptors and pointcuts to cleanly decouple code that implements functionality that should be separated. Using source-level metadata functionality, you can also incorporate behavioral information into your code, in a manner similar to that of .NET attributes. ◦ The separate Aspects module provides integration with AspectJ. ◦ The Instrumentation module provides class instrumentation support and classloader implementations to be used in certain application servers.
- 28. Usage scenarios
- 29. TYPICAL ARCHITECTURES Usual cases of the systems
- 30. •Decomposition patterns • Decompose by business capability • Decompose by subdomain •The Database per Service pattern describes how each service has its own database in order to ensure loose coupling. •The API Gateway pattern defines how clients access the services in a microservice architecture. •The Client-side Discovery and Server-side Discovery patterns are used to route requests for a client to an available service instance in a microservice architecture. •The Messaging and Remote Procedure Invocation patterns are two different ways that services can communicate. •The Single Service per Host and Multiple Services per Host patterns are two different deployment strategies. •Cross-cutting concerns patterns: Microservice chassis pattern and Externalized configuration •Testing patterns: Service Component Test and Service Integration Contract Test •Circuit Breaker •Access Token •Observability patterns: • Log aggregation • Application metrics • Audit logging • Distributed tracing • Exception tracking • Health check API • Log deployments and changes •UI patterns: • Server-side page fragment composition • Client-side UI composition
- 31. SAMPLE PROJECT Spring boot + docker and minikube
- 32. THANK YOU !