> With this transformation, microservice architectures have become the standard for building cloud native applications, and it is predicated that by 2022, 90% of new apps will feature microservice architectures.<p>What do other engineers think of this statement with regard to startups and MVPs? Am I wrong for thinking that monolithic architectures are still the best way to get started from 0? Is it simply a matter of better tooling to make creating a micro-service architecture as easy as spinning up a rails or django api?
<i>With this transformation, microservice architectures have become the standard for building cloud native applications, and it is predicated that by 2022, 90% of new apps will feature microservice architectures</i><p>Wet dreams and bunch of propaganda.
I'm excited by Dapr!<p>If I understand it correctly, it will make it easier for me to build applications by separating the "plumbing" (stateful & handled by Dapr) from my business logic (stateless, speaks to Dapr over gRPC). If I build using event-driven patterns, my business logic can be called in response to state changes in the system as a whole.<p>I think an example of stateful "plumbing" is a non-functional concern such as retrying a service call or a write to a queue if the initial attempt fails. Since Dapr runs next to my application as a sidecar, it's unlikely that communication failures will occur within the local node.<p>There seem to be extensive, nice docs on the concepts behind Dapr: <a href="https://github.com/dapr/docs/tree/master/concepts" rel="nofollow">https://github.com/dapr/docs/tree/master/concepts</a>.
Microservices is absolutely meaningless. It's just SOA (services-oriented architecture). Services = groups of functionality and business logic that interact.<p>How you deploy these services can be completely arbitrary. They can be split up in different methods, classes, assemblies, or entirely separate processes running on different servers.<p>Going straight to that last option is completely unnecessary for the vast majority. And when it's needed, it's actually because of team organization rather than app architecture.
I’ve seen small teams with microservices succeed but not in the speed at which these things promise to return value. I’ve also seen developers fail when they’ve churned out microservice after micro service and couldn’t keep up with the deployment and infrastructure overheads. As an architect I’ve recommended against some of these but what do I know. I’ve just recently asked for a service on a project and they said microservice, and then suddenly I need Orchestration and scheduling. Btw I think k8s has its place I’m not against.<p>I have seen services architected and deployed beautifully, http, tcp, MQ based, event driven, Ive designed and deployed services as windows services, and Linux based web services, http, API. Seen WCF, XML, rest, json, MQ, messaging across multiple stacks and technologies but I won’t back 90% of new apps feauturing microservices, more like 1 or 2 service endpoints, when what we actually need is governance and thought in these designs. Sometimes a service is a service but doesn’t need early optimisation. Think about decoupling and domains by all means but don’t jump into the next framework marketed at you.
So, it does messaging, pub/sub and discovery/orchestration?<p>Kind of like a Redis, possibly with an etcd - all massaged into a structured/uniform Api? Is that about right?<p>Is it only for small (ie: overengineered) setups - or is the idea that it can grow to handle millions? of messages etc?<p>Normally "does it scale?" isn't very interesting - but in this case it would seem to be redundant overhead if it <i>does not</i> let you grow to a lot of concurrent traffic?
Similar redis-based SDK we built at Elementary: <a href="https://github.com/elementary-robotics/atom" rel="nofollow">https://github.com/elementary-robotics/atom</a>
<a href="https://atomdocs.io/" rel="nofollow">https://atomdocs.io/</a><p>Definitely not as fully fleshed out but we made some choices on the serialization/pub-sub side that allowed for more efficient binary message-passing and solved some of the slow-subscriber problems for high-frequency data.
Looks similar to what we're doing with micro. We started as a Go framework and are moving to a runtime model.<p><a href="https://github.com/micro/micro" rel="nofollow">https://github.com/micro/micro</a>
<a href="https://github.com/micro/go-micro" rel="nofollow">https://github.com/micro/go-micro</a>
> it is predicated that by 2022, 90% of new apps will feature microservice architectures<p>Is this true? Do they mean partially consuming microservices or the whole project will be broken up into microservices?<p>I would've been surprised if it was 50-50 by then.
This is similar in name (and some function?) to Dapper--an Israeli startup that was sold to Yahoo!<p><a href="https://finder.startupnationcentral.org/company_page/dapper" rel="nofollow">https://finder.startupnationcentral.org/company_page/dapper</a><p><a href="http://web.archive.org/web/20090415144541/http://www.dapper.net/open" rel="nofollow">http://web.archive.org/web/20090415144541/http://www.dapper....</a>
Microservice is a model for team development. It allows the dev team easy to scale.
If you have only one developer like many startups do, it does not matter at the beginning, especially considering many startups never would have more than 2 devs before failing.
Except that Dapr is language agnostic. How would this compare to akka.net ? ( <a href="https://getakka.net/" rel="nofollow">https://getakka.net/</a> )
given the sprawl of a ton of micro-services has anyone based on a central service bus style maybe with kafka where services work a lot like unix pipes instead of ever changing APIs -- sure GRPC mitigates some of that but I am curious as having a central source of truth that is also stateful but not a relational database etc., that works and the whole pub/sub style