4

I read a lot about Microservices and their structure and it seems, that there are a lot of advantages when it comes to maintainability.

I want to build a mobile app with Spring Boot and Phonegap, which pulls news from RESTful Web Services.

So I'm thinking f building it as a microservice so I can add other services without rebuilding the whole application. Because in future I might want to add other services.

But is it really worth to build a Microservice based application for such a small mobile app?

julien
  • 624
  • 1
  • 8
  • 17

3 Answers3

6

There is a good article by Fowler, in which he poses that many projects which start off with a microservice-based design run into problems very quickly. Conversely, many successful microservice-based applications are the ones which began life as a monolith.

To sum up this principal:

...you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile.

While Fowler does not express his personal opinion on this, he does speculate on the benefits of what he calls Monlith-First.

...a monolith-first strategy, where you should build a new application as a monolith initially, even if you think it's likely that it will benefit from a microservices architecture later on...It may be hard to scale a poorly designed but successful software system, but that's still a better place to be than its inverse...you need to prioritize speed...

So, the benefits of the Monlith-First approach is that you can build a monolith quickly because generally the requirements are well known and relatively few. Additionally, you get something to market fast so then you get to understand your application and how it behaves in the real world.

What stikes me as the main benefit is that you will more clearly understand where the boundaries between the business capabilities you are supporting naturally fall within your application, than if you had tried to define these boundaries up front (a necessary and very important design step in microservice-based designs).

He goes onto expand on how you can effectively plan a Monolith-first design, which basically involves keeping your code nice and modular with an eye on the future breaking-out of modules as required.

...design a monolith carefully, paying attention to modularity within the software, both at the API boundaries and how the data is stored.

In my experience a services-based approach works well with a lot of up-front analysis time spent with business domain experts, and a mature delivery team who are comfortable working with soa and service-based in general.

tom redfern
  • 30,562
  • 14
  • 91
  • 126
  • Okay now I see the problem with a Microservice application started from scratch, there are few arguments to start with a monolithic app first. Thank your for the helpful answer. – julien Mar 10 '16 at 10:42
  • 1
    @julien - this has been asked on SO before: check this out http://stackoverflow.com/q/33041733/569662 – tom redfern Mar 10 '16 at 13:27
3

For your project a microservice architecture seems like overkill. Microservices do have a lot of benefits, but they do have a lot of operational overhead and add a lot of complexity in terms of distributed services.

It sounds like you also only have one primary requirement which is to pull news, in which case all the news-related services will form part of one microservice in any case.

Once you start adding more distinct requirement domains you could look at building them as separate microservices. Even then it might be prudent to modularize the functionality into components within the same service, and as your application and system starts to grow split the functionality out into separate microservices.

Willy du Preez
  • 1,063
  • 10
  • 12
  • I agree with you, that the app is very small with just a news service. But the in future I want to add other things, like a CMS service where an admin could post blogs and so on, thats why I am not shure about the structure. But your answer helped already a lot. Thank you. – julien Mar 10 '16 at 10:16
  • 1
    No problem. Even if you plan on adding a CMS later, there is nothing that prevents you from building the CMS as a separate service at that stage. If you do that, your biggest concern will most likely be security and being able to access multiple services, in which case looking at a token-based approach for your REST service auth upfront would go a long way. I would recommend at this stage getting something out there, paying a lot of attention to modularity within your code, and evaluating your system and needs with every new requirement (such as a CMS). – Willy du Preez Mar 10 '16 at 10:41
0

Creating a Micro Service will definitely help you in future because of the following reasons below:

  1. Scalability: Micro services can scale independently without disturbing other Micro Services used in the application.

  2. Agility: Changes in a micro service can be very quickly, thus accommodating rapidly changing business scenarios.

  3. Fault Tolerance: Even if one micro service fails, other micro services can keep servicing thus minimizing impact on the overall application

  4. Polyglot persistence: Each micro service can decide its own type of Database mechanism.

I have covered advantages of micro services partially here, there are still more.

Thus if you look at all the points above, is definitely worthy creating micro services application

shankarsh15
  • 1,947
  • 1
  • 11
  • 16