Microservices are a buzz nowadays, every group of languages has some kind of mechanism or library to apply those principles.
Sean Kelly makes a case not to use microservices in his blog post on DZone (especially for start ups), https://dzone.com/articles/microservices-please-dont?oid=hn, his argument is that when your domain is not clear yet. The overhead of adapting microservices is too great, also the increased network I/O might not be worth the extra effort.
What are you thoughts within startups?
There's no straightforward answer to whether any single technique or technology is appopriate in all settings, of course. Instead, one should ask how certain choices support or impede the current and future business needs of a startup.
Agility is usually essential for startups. If microservices enable meaningful agility for your start up, then by all means consider them. On the other hand, microservices could easily create a distraction that prevents the company from attending to higher priority business value. After all, investors and customers willl not (er, should not) care whether you use microservices or not.
I like to think abstractly about the business first. Figure out the big arc of the user story and what architecture options enable that arc. Then figure out which decisions can be deferred so as to keep options open. For an early stage start-up, it's quite reasonable to make one decision now, and another in 6, 12, or 18 months when you're smarter about needs.
One more thing: it's great for teams to have open, documented discussions for decisions like this. Ultimately, one person (typically) makes the call, but having everyone clear about the architectural themes is really heplful to teams.
It is a great article and I agree with most responses here, but let me give you my argument about the subject.
The discussion should not be about "to use Microservice architecture or not to use”, but more in the line of “what is a good architecture for my new project”.
This will of course greatly depend on you project, but, maybe there are common best practices that will help you in the long run and will not add any considerable burden and delays.
You can and probably should move progressively towards a micro service architecture. Start with some basic concepts and best practices and separate services as they become more mature in your stack and you close their features.
You should start by:
- creating stateless services
- deploying containerised services
- setup some basic communication protocols (you can start with simple ones like nats.io and later move on to Kafka or other that you prefer or better suits your needs)
- try to isolate features even in a monolithic app, this is always a good coding practice and will help you separate them into micro services later on
In the end it really depends on your needs and available developers' experience with these concepts and tools. As others stated already, the architecture is not critical at early stages, just try to comply with good code practices the rest can be addressed when needed.
Micro service is not just a buzz word, it is a necessity for many projects, the trick is for you to understand when you need it.
Some extra advice:
- Use simpler tools in the beginning. i.e.: You probably do not need Kubernetes or DC/OS(Mesos), use simpler orchestration tools like Docker Swarm or Rancher. These are considerable simpler to get into and will do the job for most cases.
- Use dedicated services to manage your statefull services like databases.
- Monitor you services and try to detect your bottlenecks.
I’m part of Altar.io, a team of experienced second time founders & world class Angular2 and Node.js developers based in London / Lisbon, helping companies building great products and data science.
*NEW* We have recently launched 10kstartup.com to help entrepreneurs build their Startup’s Web/Mobile app in 1 month for 10k USD.
If you have a brilliant idea that you want to bring to life, just drop me a few lines in a private message and let’s chat!
Thanks for reading,
Great article and question!
From my point of view, the major goal of microservices is being able to split the complexity of (big) applications maintained by a (big) team of developers into buckets so they communicate with each other through several software techniques but evolve separately and without depending on each other.
Big companies have seen on microservices the only way to keep growing their structure without having to keep suffering a big monolithic structure that translates into a big team coding and sharing the same code structure which end up being a mess.
Said that, and probably you have already noticed that I have used the word "big" so many times to clearly state that, a startup is a completely different world that IMHO just don´t fit with microservices.
At least in the form that we know microservices today, they apply such an overhead and complexity that on startups (at least 99% of them) is just not worth it.
On the tech side we are really used to hear those buzz words and want to implemented them right away but in that case is not a good fit.
Open to hear everybody else opinions!
Microservices just means having one software application that works as a bunch of separate, independent services. Those services could be APIs or something. Usually this is in the context of large enterprise-y applications that need to split up their architecture as separate services anyway. If this is something that applies to a startup, then it makes sense. I feel like most startups don't fall in that category though (they usually start off making small prototypes of apps or something) and worst-case scenario they can turn their "macroservice" into a microservice if they need to.
I think microservices architecture is a great fit for startups. It gives your team a lot of flexibility, agility, and accountability. To increase your chances of success, I recommend you put a governance process. Define the best practices and standards for the technologies that should be used.
Owing to their service oriented nature, Microservices are the angels of this year.
Microservices are a must for the following use-cases:
- Any one who has a SAAS enterprise applications with many modules.
- Any one planning to follow the Devops approach, has to have granularity described in Microservices.
- Its amazing for test/domain driven development as you can easily update or test a feature without causing any interference to the other modules.
- All loosely coupled requirements must entertain it.
- A life-saver for Fault scenarios. If there is a module which is crashing or cannot handle the traffic in a monolithic approach, it should be assigned an individual microservice.
- Top companies like Netflix, amazon have already migrated to microservices.
- Combining with Azure service fabric can manage multiple microservices appropriately (Doesnt matter if they are more than 100 microservices)
- With Azure service fabric, you can even check health state and version of each microservice in their node-cluster.
Ping me if you need help in setting up microservices or want to migrate from monolithic architecture.
Great article. Its important to not get bogged down in endless refactoring and optimization. May be I am too old for this, but don't these 5 benefits listed in the article seem familiar as solid SOA with good old software engineering practices ? In my opinion you work backwards from your customers and use whatever architecture/technology stack is needed to deliver the best possible customer experience.