Webservice - Software system designed to support interoperable machine-to-machine interaction over a network.
Microservices are small apps that comprise a bigger app and are communicating by means of uniform defined interfaces.
Advantages and Enhancements compared to monolithic application.
Microservices are small apps that comprise a bigger app and are communicating by means of uniform defined interfaces.
- REST
- &small well chosen deployable units
- & cloud enabled
Advantages and Enhancements compared to monolithic application.
- Monolytics
- Intimidating to new developers
- Overburdened developer environment - lower productivity
- Huge code base
- Scaling can be very difficult as ONLY Scale Up and get better hard ware is the only option.
- Scale out which brings infinite capacity is NOT an option here.
- Entire application has to be upgraded when every underlying Java/Java EE/apps server upgrade happens.
- Things may get worse when one tries to use different languages or frameworks for different parts of application.
- Microservices
- Individually deployable with each having separate storage system
- Decentralized data management
- Decentralized governance
- Decomposition of the application into smaller services brings smaller and reasonable code bases which are much more developer friendly.
- We can scale out each part independently depending on load.
- Independent upgrades from rest of the system.
- Flexibility of technological choices both in frameworks and languages.
- Easier to evolve
Microservices are not a silver bullet. They bring in quiet a lot of complexity in management, maintenance, deployment, coordination and system design. While individual components are simple, the big picture is more complex.
Breaking Monolith into Microservices
- No single way of breaking
- Start with apps functionality and business capabilities.
- Try to isolate that perform single business capability. Identity its dependencies and connections and draw boundaries so that two components are not connected.
- Where to start
- Begin with the component with least connections/dependencies
- Separate database access and entity definitions and not share them between components.
- Each micro component is responsible for its data.
- Avoid EJB remote or similar calls and SWITCH to HTTP(Soap/REST)
- Avoid stateful timers and schedules - externalize them.
- Separate UI
- Services everywhere for everything
- Microservices should be stateless.
- Java EE based- Payara Micro
- Payara from glassfish which provides support for full app server
- Micro version cut down to run from a single JAR for microservices. Internally it is still an app server
- Combination of Java EE & other libraries - Dropwizard
- Java framework for developing lightweight services
- Servlet, Jax-RS and Bean validation from Java EE
- Several other libraries like - Jackson, JDBI, Guava, Liquibase, and so.
- This is healthy mix of both worlds- Enterprise and non-enterprise
- This can be added as dependency and run directly from fat Jar
- Spring based - Spring boot
- Enables/supports Standalone spring applications
- Tailored for modular, lightweight apps or microservices
Stateless microservices do not keep any data that is required to execute future requests
- Use exclusively "Application Scoped" or "Request Scoped" CDI beans, or singleton instances in general
- SPA webapplications are ideal as they keep state in the users browsers.
- Continuous Integration: Practice of merging all code changes of developers as shared copy as frequently as possible.
- Continuous Deployment/Delivery: Producing software in small cycles which can be reliably release at any time
- Infrastructure as code: Monitoring and provisioning the resources
- Monitoring an logging: Ability to detect and mitigate quickly and easily.
Serverless Computing:
- A cloud computing execution model in which the cloud provider dynamically manages the allocation of machine resources
- Pricing is based on resources consumed
- Coupling is the degree of interdependence between the modules
- Cohesion is the degree to which elements inside module belong to
- Domain is the area for which software is being developed
- Model is the representation of domain. A set of abstractions that describes some aspects of domain such as relationships
Challenges
- Deciding boundries is evoutionary
- Configuration management due to number of env & instances
- Configuration server to maintain the properties of all env & instances
- dynamically distribute loads
- Naming server(Eurekha) for service registry & service discovery
- Centralized logs
- fault tolerance systems
- New technology & process adoption(different process in different technologies)
- Dynamic scaling
- Faster release cycles
- Standarize port & applicaitons
- Authentication, Authorization and security
- Rate limits - #of calls per hr
- Fault tolerance - default response when any service is down.
- Service Aggregation - External consumer who wants to call 15 services as part of a single call
- Spring Eurekha- naming server for service discovery
- Ribbon - load balancer
- Zuul - API Gateway (zuul filter for Logging,
- Spring Cloud Sleuth - Assing a unique ID to a request so that it can be traced across the components/systems.
- RabbitMQ(or we can use elastic search to consolidate & logs the logs)
- Where there is log message, microservice will put on Q. Zipkin will take from Q.
- ZipkinDistrbutedTrackingServer - to get consolidated view across all services
- At appln startup, all the micro services register with cloud bus. When there is any change in configuration, if refresh is called on any of the instances, the micro service instance sends event to Spring Cloud bus which propogates the event to all instances that were registered with it.
No comments:
Post a Comment