
Modern Applications at AWS - bryanrasmussen
https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html
======
redact207
It's sad to see this approach being pushed so hard these days. I believe AWS
recommends these things so your app becomes so deeply entrenched in all of
their services that you've locked yourself into them forever.

Unfortunately I see a lot of mid and senior devs try to propose these
architectures during interviews and when asked questions on integration
testing, local environment testing, enforcing contracts, breaking changes,
logical refactoring a lot of it falls apart.

There's a lot of pressure for those guys to deliver these sort of highly
complex systems and all the DevOps that surround it when they enter a new
company or project. Rarely is the project scope or team size considered and
huge amounts of time are wasted implementing the bones since they skip the
whole monolith stage.

Precious few companies are at the size where they can keep an entire Dev team
working on a shopping cart component in perpetuity. For most it's just
something that gets worked on for a sprint or two.

AWS made a fundamental assumption in this that monoliths and big balls of mud
are the same thing. Monoliths can and should be architected with internal
logical separation of concerns and loose coupling. Domain driven design helps
achieve that. The other assumption that microservices is a fix to this isn't,
because the same poor design can be written but now with a network in between
everything.

I think this advice is worth a read, but it's not law. The most pragmatic
approach to microservices is to start with a monolith and shave off the
intensive parts to separate services as you need to.

~~~
mattbillenstein
Yes! Been preaching this for years!

I've untangled more than a couple small eng teams (~ < 20 devs) that were
trying to do microservices using this recipe on aws and just horrendously
failing at it.

A well-architeched monolith will really go a long way - generally perhaps
easily up to 100 or more devs before thinking about microservices.

~~~
shantly
\- If it doesn't have _very_ different scaling needs from the rest of the
application, probably don't make it a microservice.

\- If it isn't something you could plausibly imagine using as a 3rd party
service (emailer/sms/push messages, authentication/authorization, payments,
image processing, et c.) probably don't make it a microservice.

\- If you don't have at least two applications at least _in development_ that
need the same service/functionality, probably don't make a microservice.

\- If the rest of your app will completely fall over if this service fails,
probably don't make it a microservice.

\- Do write anything that resembles the above, but that you don't actually
need to make a microservice yet, as a library with totally decoupled deps from
the rest of your program.

------
DVassallo
> To succeed in using application development to increase agility and
> innovation speed, organizations must adopt five elements, in any order:
> microservices; purpose-built databases; automated software release
> pipelines; a serverless operational model; and automated, continuous
> security.

When I worked at AWS, it used to take us months to change the position of a
button in the UI. Things that our competitors did in hours and days, we did in
months and years.

I'd say that as a general heuristic, if you want "to increase agility and
innovation speed" do the opposite of what Amazon does.

~~~
segmondy
An interface even if it's just a user interface is a contract. You can't just
go changing it because you want to. Many immature companies do this and think
it's innovation. It's not, all your users will have to relearn the new UI
change.

~~~
DVassallo
That attitude is what leads to the AWS console.

~~~
yongjik
As someone who uses AWS console every day at job, I must say I find it pretty
usable. I especially like the part that whatever buttons I learned stays in
the place, so I don't have to waste time figuring out what the hell I have to
press this time.

So if AWS's attitude lead to its console, I think they're doing great.

~~~
aftbit
As someone who uses the AWS console once a month, I find it incredibly
confusing and I'm always hunting for the right sub-section. This is the old
trope: experts prefer complex and efficient systems, while beginners prefer
simplicity.

------
ilovecaching
I have a request for opinions!

I’ve noticed that software quality never seems to enter into conversations
about scaling. Do code hygenie, writing clean code, and good documentation not
matter when you’re moving fast and growing like crazy? I’ve noticed the
approach seems to be to focus on operations rather than the way the code is
written. Use CI, monitoring, organize teams around services, etc. From my
friends in the bay however, I hear the code itself is mostly written and band
aided over and over again with refactoring and rewriting seen as “wasting
time” when you could be writing more band aids or improving operations.

Does the band aid and if it’s not broke don’t fix it and do exactly what you
need to fix it approaches really yield the same or better results as
approaching software as a craftsmen? How do you convince an AWS engineer that
these things are important when what’s in prod is working and a rewrite just
seems like pot stirring? Or a refactor isn’t critical work to add more
features?

------
laluser
For large corporations like Amazon, there are huge opportunities to move to
Lambda. Back when I worked there, teams would over-provision their services
like crazy. Most of it to scale for the holiday season. Most teams would not
give that extra capacity back.

~~~
vinay_ys
how long ago was this?

~~~
laluser
This was < 2 years ago

------
treggle
Cloud applications have become much much more complex than OS based
application development.

Don’t take the path of cloud based development if you are aiming to simplify.

