I have built few microservices that consume a number of external services. Few of these external services are consumed by more than 1 microservice that I have built. I have built the connectors to these microservices as a library project and have included it as a dependency in all my microservice projects. However I read that all logic for microservices should be self contained and duplication of logic is ok. If that's the case , is it recommended for me to define these connectors within each every microservice instead of having a shared library?
...all logic for microservices should be self-contained and
duplication of logic is ok
I think this is the core of the issue you are struggling with. Is this statement actually true?
A quick google search later:
http://www.simplicityitself.io/our%20team/2015/01/12/sharing-code-between-microservices.html
This article talks about this exact question, which we can now frame as What is the appropriate level of re-use in microservice architecture?
The author provides a list of reasons why developers feel the need to share code, ordered from lowest to highest in terms of coupling and loss of isolation:
Leverage existing technical functionality
Sharing data schemas, using a class, for example, as an enforcement of a shared schema.
Sharing data sources, use of the same database by multiple services.
Though this list covers most of the reasons, I would add another important reason to share code, which is to do with a common framework for rapid standing up of microservices, commonly called the Microservice Chassis pattern.
The author goes onto say:
It is of utmost importance to pin down your motivation for wanting to
share code, as unfortunately there is no right answer to this
question. Like everything else, it’s contextual.
So, all that said, should you centralize your connectors or not?
Well, where do these dependencies fit in on our list? And what degree of coupling can you endure before you're no longer doing microservices but building a monolith instead?
These are not easy questions to answer, but hopefully this will help guide you to the correct conclusion.
Related
We have a huge monolithic backend application built on Java-Spring that deals with the Checkout functionalities of an e-commerce retail client. The application exposes multiple REST APIs to deliver the functionalities and uses a No SQL DB to store the data.
What type of Microservices design/architecture can we go for, if we want to break this down into granular micro services so that the code maintainability and deployments can be made much easier? Could anyone please suggest the best suitable options that we could try out?
An incremental migration from monolith to micro-services is a safer path, you would find something called strangler pattern, which is a famous approach. Following is a good article I came across.
https://dzone.com/articles/monolith-to-microservices-using-the-strangler-patt
Firstly, you should be able to decompose your system in various aspects in terms of functionally and technically. You would need to find more information of what strategy to go forward, following research paper is a good start.
http://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf
I have created a simple blogging application using Spring Boot and RESTful APIs. I have connected the same to a MySQL database to run some SQL queries like those for adding a blog, deleting a blog, etc.
My questions are as follows:
Does it mean that I have used a microservice architecture? When does an architecture become a microservice? (I ask because many similar websites call an application as microservice-based. Other than the main application, e.g., currency exchange instead of blogging, I see no other difference; for e.g., this one - it does have many more aspects, but they are not contributing to its microservice-ness, IMHO).
Can I call an application as horizontally scalable if I am using microservice-based architecture?
Note: The tutorial I followed is here and the GitHub repo is here.
First of all: those aren't exact yes/no questions. I'll give you my opinion, but others will disagree.
You have created what most people would agree qualifies as a Microservice. But a Microservice does not make a Microservice architecture, in the same way that a tree doesn't make a forest.
A Microservice architecture is defined by creating a greater application that consists of several distributed components. What you have done is created a monolith (which is absolutely fine in most cases).
Almost every talk about Microservices that I have attended has featured this advice: start with a monolith, evolve to microservices once you need it.
Regarding the last question: your application is horizontally scalable if it is stateless. If you keep any session state, it can still be horizontally scalable, but you'll need a smart LB managing sticky sessions or distributed sessions. That's when things get interesting, and when you can start thinking about a Microservice architecture.
Common problems are: how can I still show my customers my website, if the order database, cart service, payment provider etc. are down. Service discovery, autoscaling, retry strategies, evolving Rest apis, those are common problems in a Microservice architecture. The more of them you use and need, the more you can claim to have a Microservice architecture.
Not at all. The use of microservices is an advanced architecture pattern that is hard to implement right, but that gives useful benefits in huge projects. This should not be of any concern to a small project, unless you want to test this particular architectural style.
Breaking an application in smaller chunk does increase its scalability, as resources can be increased on a smaller scale. However, statelesness, among other properties, are also key components to a scalable architecture.
First of all, what you showed us dont looks like microsservice at all.
You can say that you have an application that uses microsservices architecture when it is formed by microsservices(oh rly?) with independent functionalities and that can be scalable. Scale one service, means that you will run multiple instances (possible in multiple hosts) and it will be transparent for other services.
A good example to ilustrate that is a web store microsservice based composed by 4 microsservices:
Sale Microsservice
Product Microsservice
Messaging Microsservice
Authentication Microsservice
In a blackfriday event, for example, which theoretically will occur a lot of purchases, you can scale only the Sale Microsservice, saving resources from the other three (of course this means using a bunch of other technologies like proxy, LB ...). If you were using a monolithic architecture would need to scale all your application.
If you are using correctly a microsservice architecture, yes, you can say that your application is horizontally scalable.
In a context of several spring boot apps, sharing some components, is that considered as a bad practice to publish an artifact used in those apps?
I'm planning to reuse controllers and services abstracts and low level classes (for statistics requiring fast write access, so webservices are excluded).
There are two contrary paradigms, both definitely make sense on their own, but in this case they front each other. Hardcore microservice evangelists would roughly claim that there should be no common dependencies at all to reduce coupling between the different services / applications. That means although in case the services share many architectural patterns, you have a lot of "copy and paste" code. And exactly that would make the don't repeat yourself faction angry, because it makes also sense thinking about why not sharing already implemented functionality.
So the correct answer is: "It depends." It will always be a tradeoff between following the one law by violating the other. You can just make an economical / cost-effective decision and figure out what is feasible for your infrastructure and what causes less technical debt.
Suppose I have a very large-scale server-side web application written in JavaEE (and related technologies classically combined with it), and I decided to migrate it completely to Akka (and related technologies usually combined with it, including moving the code to Scala). The reasons of the migration decision are not important: suppose I have to do it, and that's all to it.
My question is: What would be the strategy to follow here, aiming to optimize the migration time and the scalability of the resulting application?
If the question lacks of details, I can provide some, although I would like to hear strategies without being very specific.
This is an open ended question. But let me try and give you some ideas. Having worked with both J2EE as well as Play2/Akka/Spray.io (Scala) based system I can provide you will the following high level/general guidance for migration.
Partition your system: Partition your current system based on functionality and rank them according to their criticality to business, your stakeholders and clients. Partitions can done based on different dimensions ( architectural components at runtime, business features, development team/modules) etc. You also need to find dependencies between these partitions.
Identify candidate partition: Once you have ranked partitions, it’s useful to pick the smallest possible partition that overlaps in as many dimensions as possible and has the least amount of coupling. Usually this is the case if your initial architecture is modular.
Implement a prototype: Take the candidate partition and create a prototype that provides the same functional capability. Now evaluate and compare the new capability against the old in terms of various quality attributes (performance, modifiability, extensibility etc). The prototype will also give you an estimate of technical risk, challenges, and effort.
Create a new architecture: I think at this point you should have enough input to create the first version of your new architecture. Also identify how capabilities of other partitions will be implemented in this new architecture. Selecting the most complex partition and try to map it to this new architecture is really good exercise and can massively reduce your technical risk in the future.
Field the prototype: Try to field the prototype to a small subset of users/stakeholders and get feedback. Decoupling the prototype using REST/pub-sub interfaces is a good idea.
Plan for migration: Create a plan and schedule for rest of your system.
I can be more specific if you provide more targeted questions.
We're developping a software for a large bank. So, the problem is that bank operates in SOA way. I mean, we have an entry point to the system and then there are WebServices fow everything, and when I tell everything, I mean EVERYTHING, there are like 3500 services.
Right now these services are just stored in a database table with (or without, sometimes) their descriptions, so, you can imagine the hell we're living in. I guess that sometime it's easier to implement new web service than to find the right one, this produces redundancy.
So, my question is, is there some way of organizing this kind of stuff? I mean, we have many bussiness lines and some common components, but I'm totally newbie in WS. Anyway, I need some kind of way to provide the developers with information what service they can use in any case.
A good documentation may help. Or google for the more sophisticated approaches like web service registries using WS-Inspection or UDDI.
I've seen it done with a simple web site where developers can find descriptions, WSDLs, etc. I think it's sufficient; I wouldn't recommend UDDI or buying a sophisticated tool. Yours is a problem in advertising and marketing.
High Level Logic: Rethinking Software Reuse in the 21st Century
http://highlevellogic.blogspot.com/2010/09/high-level-logic-rethinking-software.html