
Dapr: an open-source project to make it easier to build microservices - gabrtv
https://cloudblogs.microsoft.com/opensource/2019/10/16/announcing-dapr-open-source-project-build-microservice-applications/
======
shaneprrlt
> 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.

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?

~~~
chooseaname
I think it is crazy. Why would 90% of new apps need to feature microservice
architectures for any other reason beside padding out resumes?

~~~
eweise
You don't need microservices if you think your business will eventually fail.
On the other hand, if its a success then at some point microservices are much
more maintainable. Its extremely difficult to change a monolith to
microservices. Right now there is a heavy infrastructure prices to pay for
microservices but if that gets solved then why would you not start with
microservices?

~~~
xorcist
> Its extremely difficult to change a monolith to microservices

I beg to differ. It's completely straightforward, for the most part. You split
them out, one by one. That's a big part of the reason for its popularity.

If it's really that difficult, maybe it's not a great fit for the problem at
hand.

~~~
asdfman123
No, the problem is it can be extremely easy to break services into
microservices, especially using the slick tools I've seen in Azure (I'm sure
other providers have them as well). They just work, and they're cheap!

But then you realize debugging and refactoring is way harder, and you aren't
getting any real benefits from splitting things apart like that.

------
FpUser
_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_

Wet dreams and bunch of propaganda.

------
adamfeldman
I'm excited by Dapr!

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.

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.

There seem to be extensive, nice docs on the concepts behind Dapr:
[https://github.com/dapr/docs/tree/master/concepts](https://github.com/dapr/docs/tree/master/concepts).

~~~
adamfeldman
I like the idea of actors to encapsulate state management for my aggregates (a
la Domain Driven Design). But I haven't wanted to be limited to just using
Elixir/BEAM or an actor toolkit on the JVM.

I'd wager that Dapr's virtual actors [1] were inspired in-part by Microsoft's
work on Orleans [2]. I've read through some of the Orleans docs, and Dapr
looks to be a more accessible (cross-language, non-CLR!) way to build using
some of Orleans' concepts and capabilities.

!! this is super cool: "You can also perform aggregate queries across actor
instances, avoiding the common turn-based concurrency limitations of actor
frameworks [3].

[1]:
[https://github.com/dapr/docs/tree/master/concepts/actor](https://github.com/dapr/docs/tree/master/concepts/actor)
[2]: [http://dotnet.github.io/orleans/](http://dotnet.github.io/orleans/) [3]:
[https://github.com/dapr/docs/blob/master/concepts/state-
mana...](https://github.com/dapr/docs/blob/master/concepts/state-
management/state-management.md)

~~~
nicocesar
Dapr's virtual actors sounds like a good idea, but besides the API spec[1] is
there any _better_ doc to have a look to an example? How are the callbacks
used..?

I want to give it a try, but really seems that is pre-alpha.

[1]
[https://github.com/dapr/docs/blob/master/reference/api/actor...](https://github.com/dapr/docs/blob/master/reference/api/actors.md)

------
manigandham
Microservices is absolutely meaningless. It's just SOA (services-oriented
architecture). Services = groups of functionality and business logic that
interact.

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.

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.

------
quintes
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.

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.

~~~
asdfman123
Microservices are usually a bad idea for software unless your whole business
model depends on lots of people using your software down the line. It's
certainly not good for internal software.

What people really need to do is follow SOLID principles, use interfaces
appropriately, and just generally practice good architecture.

The real benefit is the separation of concerns, which microservices promises
to deliver. But well designed software does that too, and you don't have the
headache of coordinating all that hardware.

I guess it's easier to sell something trendy to upper management (we're doing
the new, hot thing) than to sell a code rewrite (we're not going to ship new
features for a while as we opaquely push around code).

------
e12e
So, it does messaging, pub/sub and discovery/orchestration?

Kind of like a Redis, possibly with an etcd - all massaged into a
structured/uniform Api? Is that about right?

Is it only for small (ie: overengineered) setups - or is the idea that it can
grow to handle millions? of messages etc?

Normally "does it scale?" isn't very interesting - but in this case it would
seem to be redundant overhead if it _does not_ let you grow to a lot of
concurrent traffic?

~~~
yaronsc
Hey e12e, Dapr is meant for both small or large setups. It's designed to
handle your scale as it grows and be highly performant.

Dapr itself is a sidecar - it can be easily autoscaled by external autoscalers
like Kubernetes offers, KEDA and others.

~~~
e12e
Hm. So there is some magic to avoid all roc calls and pub/subs going _through_
dapr?

Eg: if I have a thousand users subscribed to a channel - only setup would
involve dapr, and the rest would be dependent on my pub/sub queue manager (eg:
plain redis, or rabbitmq) keeping up?

But from the [ed: dapr api microservice component] consumer viewpoint it's
just "ask dapr for subscription", "ask dapper to broadcast a message" \- and
you're off to the races?

~~~
yaronsc
Having the calls go through Dapr is actually a pretty powerful feature: Dapr
will handle retries and handle failures and guarantee an at-least-once
delivery. For high-throughput scenarios we have a gRPC client which can see a
much higher throughput than regular HTTP.

Yes, you are right: from the consumer's viewpoint, it's "ask to subscribe, ask
to publish a message" and you're off.

~~~
e12e
So it would be fair to say that dapr scales to "fairly big" throughput - but
not the right tool if your goal is in the ballpark of saturating a 10gps
network with messages?

(mind, I have no such ambissions presently, just trying to get my head around
what dapr is - and is not)

~~~
SideburnsOfDoom
> but not the right tool if your goal is in the ballpark of saturating a 10gps
> network with messages

If that's in any danger of happening, then you scale out not scale up. e.g.
run 100 worker instances to process the messages. each one gets 0.1 gps of
messages.

Microservices are good at scaling out as needed. I mean, not completely
painless, but better than the alternatives.

~~~
e12e
Right, I know the example is somewhat hyperbolic - but one could argue that
it's quite possible to build a micro service architecture around zeromq or
rabbitmq - and those systems should (in theory) allow you to max out your
modern hardware.

So in the sense that you might not really need micro service architecture for
your regular "new thing" (ie you can run it on a modern server with 128
threads and it fits in half a terabyte of ram or some such "medium" size
workload) - it's interesting to see how dapr affects you if you do need to
scale.

If you struggle with N to M messaging, you might not want to multiply N and M
with Y dapr nodes-because that might make your solution more difficult to
scale.

That said I think there's a valid case to be made that it can be valuable to
suffer a micro service architecture and the possibly massive signaling
overhead - not to "scale", but to gain resiliency and stability. Failover,
easier deployment of new code etc.

Basically anything that can give you "works like big iron" on whatever scraps
of commodity hardware you're able to rent.

~~~
SideburnsOfDoom
> you might not want to multiply N and M with Y dapr nodes

That would be bad, but my understanding of the "sidecar" is that there would
be M dapper nodes, each attached to a main consumer in a container. (and
probably add N dapper nodes as well, if the N senders are also containerised
and managed this way)

------
dpipemazo
Similar redis-based SDK we built at Elementary:
[https://github.com/elementary-robotics/atom](https://github.com/elementary-
robotics/atom) [https://atomdocs.io/](https://atomdocs.io/)

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.

------
chuhnk
Looks similar to what we're doing with micro. We started as a Go framework and
are moving to a runtime model.

[https://github.com/micro/micro](https://github.com/micro/micro)
[https://github.com/micro/go-micro](https://github.com/micro/go-micro)

------
kornish
Confusingly, Google's internal microservice tracing framework is called
Dapper:
[https://ai.google/research/pubs/pub36356](https://ai.google/research/pubs/pub36356)

~~~
pixelbath
It is also the name of the object-mapping framework created by Stack Exchange:
[https://github.com/StackExchange/Dapper](https://github.com/StackExchange/Dapper)

~~~
SideburnsOfDoom
Yep, we use Dapper the micro-ORM in .NET code.

This is a name clash.

~~~
markdoubleyou
It is predicted that by 2022, 90% of new apps will feature a name that's a
spelling variation of the word dapper.

------
dmix
> it is predicated that by 2022, 90% of new apps will feature microservice
> architectures

Is this true? Do they mean partially consuming microservices or the whole
project will be broken up into microservices?

I would've been surprised if it was 50-50 by then.

~~~
asdfman123
More like "By 2022, 90% of developers will have been burnt by microservices
and vow to never do them again."

~~~
dragonelite
Then we will see a shitload of articles popping up "10 reasons why Monolithic
software development was the right way" and "How we reduced cost by merging
all our micro services back to a monolith!!!11!!".

------
amitport
This is similar in name (and some function?) to Dapper--an Israeli startup
that was sold to Yahoo!

[https://finder.startupnationcentral.org/company_page/dapper](https://finder.startupnationcentral.org/company_page/dapper)

[http://web.archive.org/web/20090415144541/http://www.dapper....](http://web.archive.org/web/20090415144541/http://www.dapper.net/open)

~~~
asdfman123
Not to be confused with the other Dapper, which is a .NET micro ORM.

------
Ciantic
It sounds like a service mesh, it can even be ran as a sidecar like linkerd or
istio. However it seems to do more, like pub/sub events.

------
xmly
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.

------
chooseaname
Does your Dapr microservice use Dapper?

------
NicoJuicy
Except that Dapr is language agnostic. How would this compare to akka.net ? (
[https://getakka.net/](https://getakka.net/) )

~~~
weq
I think Dapr compares to my Rxns framework for building vendor-agnostic
microapps.

Because your front-end is also a micro-service.

[https://github.com/captainjono/rxns/](https://github.com/captainjono/rxns/)

------
gigatexal
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

------
TheHwangover
So does this mean that Service Fabric is officially dead? Looks like they're
trying to sweep that failed project under the rug

~~~
teeboy75
Far from it. Although Dapr borrowed the Actor Framework and Stateful features
from Service Fabric, There are a couple of major differences. a) Stateful
services: Your code + data wont' live together on dapr. You would need an
additional I/O hop to access cosmos or redis [or your own state provider] to
get to the data. In service fabric, once you hit a partition the data lives
right there on that node. You will get much lower latency for reliable
collection reads with Service Fabric. b) Service fabric runs classic .net and
.net core. Dapr is only for .net core projects. This is a big deal for users
who have vast assets on classic .net c) With external state provider,
partitioning becomes a little murky on dapr. Service fabric gives you range
and named partitions with replicas. I am not clear how dapr handles replicas
or it delegates that to kubernetes or the underlying orchestrator. d) Service
Fabric roadmap: [https://github.com/Microsoft/service-fabric#service-
fabric-r...](https://github.com/Microsoft/service-fabric#service-fabric-
release-schedule)

------
wwarner
[https://github.com/dapr/dapr](https://github.com/dapr/dapr)

------
xmly
It like what AWS Lambda Runtime does. In lambda, your code is actually talking
with a local actor to send and get events.

------
FpUser
I was gonna run this through bullshit detector but it choked and died halfway
through

------
tbern02
this actually looks really promising

