Is this application developed by me a microservices application?

[Monica Shiralkar]

I worked on an application where I needed to create API for sending notification which can be either email or sms. Instead of creating a single rest application having all responsibility , I decided to create 3 different Rest APIs (using spring boot) with different single responsibilities  such that the first API sends the Email, the second API sends SMS while the third API either calls the first or second API based on a parameter which tells whether user wants to send email or sms. So I have 3 different APIs under the same project having single responsibility. Is this application which I created a microservices application?

Thanks

[Tim Holloway]

Sounds good to me.

Then again, if I had a single-contact web service API and it did the email and/or sms in the same app and that's all it did, I'd still count it as a micro-service.

[Monica Shiralkar]

Tim Holloway wrote:
if I had a single-contact web service API and it did the email and/or sms in the same app and that's all it did, I'd still count it as a micro-service.

In microservice, each will be doing only 1 responsibility whereas here I can see that 1 api having 2 responsibilities that is sending sms as well as sending email. How can it be microservice in that case?

[Tim Holloway]

You're looking at implementation. I'm looking at function. If the ultimate purpose is to send a message, regardless of transport and no other system calls the low-level transports directly, then it's not really necessary to make each one an independent app. Neither SMS nor email are all that big. And actually, I'd probably be using email to send SMS myself.

[Monica Shiralkar]

Thanks.I was thinking that had I created single api in this case it would have been monolithic application and since I instead created 3 APIs which single responsibility, it is now microservice architecture. This is wrong as you said. So what would be an example of microsevices application as compared to example of monolithic application for the same functionality?

[Tim Holloway]

An API is not a single method definition, it's a set of related method interfaces. For example, the JEE API, which has interfaces full of methods for servlets, Http request and response objects, http sessions, and so forth.

What makes a microservice a microservice is primarily its function, not its construction. Basically, a microservice should do one thing and do it well. That doesn't mean that it cannot do one thing in many ways or even have many methods to talk to it, merely that it's primarily doing a single job and not a set of jobs the way a traditional web application with GUI web pages would.

[Tim Moores]

If you're looking for hard and fast rules about what constitutes a microservice design, there are none. Or, depending on how you look at it, there are plenty :-) While Wikipedia isn't generally the best of sources for software engineering, it gets it just about right in the introduction to Microservices:

There is no single definition for microservices. A consensus view has evolved over time in the industry. Some of the defining characteristics that are frequently cited include:

And then it goes on. Specifically it says "Services are organized around business capabilities." So in your example, it would depend on whether the difference between sending a message via SMS or sending it via email is an important distinction for the business - which might or might not be the case. I think I'd side with Tim that functionality is key, and that this difference is not usually germane to that.

[Monica Shiralkar]

Tim Holloway wrote:
What makes a microservice a microservice is primarily its function, not its construction.

In first case the function of first API is only to send email, the function of second API is only to send sms, the function of third API is only to call email/sms API based on user input. In the second case the function  of this single API is to decide whether to call sms or email api as well as calling the appropriate api.  

[Tim Holloway]

Unless I'm mis-reading, the only API actually seen by the AP (Application Program) is the one that determines which of the other 2 services to call. In which case, the only real business function is to send a message, irrespective of what transport will be chosen. There's no real benefit for breaking the backend services out into separate micro-services unless it's intended that they also be callable directly by application programs.

[Monica Shiralkar]

Tim Holloway wrote:There's no real benefit for breaking the backend services out into separate micro-services unless it's intended that they also be callable directly by application programs.

Yes there is no benifit. I could have kept separate classes for smssender and emailsender and that would have been enough instead of different APIs. This is a wrong example of breaking into microsevices. What would be a right example for breaking into microservices?

[Tim Holloway]

I'd say that if the apps were combined into a single app that that would make an excellent example of a microservice.

[Monica Shiralkar]

In microservices, instead of a big monolithic application it is broken down into multiple small services each having only 1 single responsibility.   These services communicate with each other.  Do these small services have to be under same project or separate project for each. Does these services communicating with each other mean one orchestrator service calling and using the other small services?

[Monica Shiralkar]

Thanks

Tim Holloway wrote:I'd say that if the apps were combined into a single app that that would make an excellent example of a microservice.

If I have a shopping cart application. In first case I break the application into 3 services. One applicaton for front-end , one application for APIs which are called from the front end applicaton and one applicaton for a notification API service application (used for sending notification to the customers) instead of having a single monolithic application having all these 3 in a single project.  Is this an example of microsevices?

[Tim Moores]

Monica Shiralkar wrote:Do these small services have to be under same project or separate project for each. Does these services communicating with each other mean one orchestrator service calling and using the other small services?

"Project" is not the important factor - a project could create multiple deployable artifacts (although I would consider that bad design, if the artifacts were independently deployable, and meant to be so). But yes - generally you would have multiple independently buildable and deployable artifacts in a microservice architecture.

In first case I break the application into 3 services. One applicaton for front-end , one application for APIs which are called from the front end applicaton and one applicaton for a notification API service application (used for sending notification to the customers) instead of having a single monolithic application having all these 3 in a single project.  Is this an example of microsevices?

I think you meant "3 applications" rather than "3 services". "frontend" could conceivably be quite big and monolithic, as can "APIs which are called from the front end applicaton". So whether that implements a microservice architecture is unclear form the details you have provided.

[Monica Shiralkar]

Tim Holloway wrote:Unless I'm mis-reading, the only API actually seen by the AP (Application Program) is the one that determines which of the other 2 services to call. In which case, the only real business function is to send a message, irrespective of what transport will be chosen. There's no real benefit for breaking the backend services out into separate micro-services unless it's intended that they also be callable directly by application programs.

Thanks.If I remove the third API and now there are only 2 APIs and both being called from Application program  : one sending SMS and the other sending Email, then will it be a correct example of microservices?

[Monica Shiralkar]

Tim Holloway wrote:

Then again, if I had a single-contact web service API and it did the email and/or sms in the same app and that's all it did, I'd still count it as a micro-service.

Thanks. But if they are in same app, if tomorrow SMS functionally requires change, the whole app will have to be deployed. And thus during the deployment time both SMS and email functionalities will have to be down for some time.Would that not be more like monolithic ?

[Tim Holloway]

If you have an Email/SMS microservice and it changes, the only other microserves that should require alteration and thus rebuild/redeploy are the ones which are impacted by those changes. If I add a new API function to email, i'd only have to worry about the upstream services that want to add this new functionality. If I change an API method prototype (generally, it's better to deprecate and add a new one), that would require upstream micro-services that use that method to be updated, built and deployed. When using a templating system based on a Java Interface, create a new Interface for the template and leave the old one. As I said. it's better to deprecate and add.

On the downstream side, it's most likely that your changes would be adding new downstream micro-services or taking advantage of previously-unused or new downstream functions. So if you're adding a new downstream micro-server, you'd typically deploy it before changing your upstream micro-service.

All this is where you can really appreciate DevOps tools. In fact, it's very much like something I've been doing this week. And thankfully, finally finished. Rant: If people are going to provide essential third-party software software and write it in exotic languages, they owe it to make said apps as robust and self-diagnosing as possible. And to allow for the fact that some heavily-used commercial OS distros deliberately employ very old libraries, APIs and utilities, which can can result in obscure breakdowns if you insist on using the latest-and-greatest without consideration.

[Monica Shiralkar]

Tim Holloway wrote:If you have an Email/SMS microservice and it changes, the only other microserves that should require alteration and thus rebuild/redeploy are the ones which are impacted by those changes.

Okay.And how about just having 2 microservices SMS service  and Email service as different microservices such that when SMS service has been changed and is being deployed , there is no downtime for that time and likewise when Emàil service has been changed and is being deployed , no downtime for that time ? Thus ,can I call this as an example of micro services.

[Tim Holloway]

Yes you could. And ordinarily I would have, but one way for a server to send SMS messages is to email them, so I considered a combined SMS/email microservice. Of course, there's no law that says that you can't interweave microservices, though it does make it a little harder for people to follow. So you could just as easily have an SMS microservice that invokes the emaill microservice even if their upstream microservice calls SMS as well as direct email.

[Monica Shiralkar]

Thanks.Okay, just for my understanding in my example if  ignoring just for now the special case that email can be used for SMS,.is the below correct :

Case 1
2 APIs : one for SMS Service and other for Email service

Case 2

1 API both having email service and SMS service methods


Case 1 - Microservices.
Case 2- monolithic

It is correct ?

[Tim Holloway]

No, because I'm assuming that SMS+email are not the primary upstream service but rather a microservice that some other application(s) are using.

[Monica Shiralkar]

Thanks.
Are the below two microservices?

Microservices 1 - Application with REST APIs for notification (Email and SMS).

Microservices 2-Application with REST APIs for interacting with the SQL database.These APIs are meant to be called from the front-end.

[Ron McLeod]

Sure - both could be microservices.

Monica Shiralkar wrote:Microservices 1 - Application with REST APIs for notification (Email and SMS)

Sounds like a Notification Service.  The service would likely be able to deliver Email-based notifications directly, but would probably call on another service to deliver SMS-based notifications (SMS messages are delivered over the PLMN, not the Internet).

Monica Shiralkar wrote:Microservices 2-Application with REST APIs for interacting with the SQL database.These APIs are meant to be called from the front-end.

This could be a (Generic) Storage Service, maybe something like Redis or Memcached.

[salvin francis]

I see that your posts mentions "Microservices 1" and "Microservices 2". I think Ron's post points out something very valuable here. "Notification Service" and "(Generic) Storage Service".

Like TM pointed out above, "Services are organized around business capabilities.". If you are able to name those services in the first place, I think you have a distinction right there. If you are not able to find a simple name and come up with convolutions, it would sound like more than one service crammed into a single one.

[Monica Shiralkar]

Thanks all. My misunderstanding about Microservices got cleared now..

[Monica Shiralkar]

salvin francis wrote:I see that your posts mentions "Microservices 1" and "Microservices 2". I think Ron's post points out something very valuable here. "Notification Service" and "(Generic) Storage Service".

Like TM pointed out above, "Services are organized around business capabilities.". If you are able to name those services in the first place, I think you have a distinction right there. If you are not able to find a simple name and come up with convolutions, it would sound like more than one service crammed into a single one.

Yes, thinking this way would be the best while going for Microservices.

[Monica Shiralkar]

Suppose I have an application where first the user creates Configuration Data from UI, which gets saved into the database. Input Data comes into the application and gets processed and based on some criteria notifications are sent to the users.
For this I think, I can break this into 4 microservices:
1. UserConfigurationUIApp  (user accesses this API to save configuration into the DB by calling the StorageServiceApp listed as 2.
2. StorageServiceApp (REST APIs which does CRUD operations for the user configuration data with the SQL database).
3. InutDataProcessingApp (Application to process the input data) and if the criteria passes call the NotificationServiceApp listed as 4 to send the notifications to the users.
4. NotificationServiceApp (REST APIs to send notifications which can be SMS/Email).

Does that look correct?