
AWS Mesh Generally Available - aginovski
https://aws.amazon.com/about-aws/whats-new/2019/03/aws-app-mesh-is-now-generally-available/
======
rocgf
> App Mesh uses the open source Envoy proxy, making it compatible with a wide
> range of AWS partner and open source tools.

Yet another Amazon product based on open source software, while still
contributing almost nothing to this space.

~~~
greyskull
[https://github.com/envoyproxy/envoy/pull/5580](https://github.com/envoyproxy/envoy/pull/5580)
and
[https://github.com/envoyproxy/envoy/pull/5887](https://github.com/envoyproxy/envoy/pull/5887)

It's a start. Looking forward to more contributions from the team.

~~~
sergiotapia
Amazon should be pumping hundreds of thousands of dollars into all these open-
source projects they're leveraging.

~~~
sa46
So 1 full time software engineer on open source projects? Looks like they
vastly exceed that already
[https://aws.amazon.com/opensource/](https://aws.amazon.com/opensource/)

------
erulabs
Envoy must have one of the fastest adoption stories in the history of FOSS. It
is excellent software, although the space is full of contenders - Traefik and
Istio are also exciting projects!

~~~
stock_toaster
And linkerd (2.0) too.

~~~
inquisitiveio
I'm pretty sure linkerd 2 has switched to their own rust/tokio based solution

~~~
spockz
They do and that is why they are a contender. Not a user of envoy.

------
Cacti
One more new cloud service intended to fix what’s wrong with existing cloud
services. At what point do you just go back to traditional app architecture
with normal servers?

~~~
bg24
My understanding is that it solves a specific customer problem by seamlessly
connecting the workloads running on various forms (ec2, ecs, k8s etc.).

------
wstrange
I really wish Amazon would have contributed resources to istio instead of
rolling their own mesh...

------
reilly3000
How does App Mesh vs Istio shake out? I’ve been reticent to use Istio on GKE
but it seems to offer some great features. Something with this basic feature
is pretty useful with just a few more micro services, than I current manage.

~~~
greyskull
I'm not super well versed frankly but my attempt:

They're both control planes for envoy proxy. App Mesh is a managed proprietary
solution, Istio is open source and self-hosted but there are managed options
available. Istio explicitly supports k8s and consul; app mesh doesn't care
where the envoy proxies run (great for migrating).

I _think_ Istio is a full knowledge model where everyone knows about everyone
else in the mesh, App Mesh is explicit. The configuration pushed to the
proxies only have the targets that have been modeled as such in the app mesh
model (great for larger organizations).

App Mesh roadmap: [https://github.com/aws/aws-app-mesh-
roadmap](https://github.com/aws/aws-app-mesh-roadmap)

Istio's: [https://istio.io/about/feature-
stages/](https://istio.io/about/feature-stages/)

------
guhcampos
I can't really disagree with Redis here.

Traditional licenses forced you to contribute back if you used community's
code. SaaS changed everything: you can now "leech" software without giving
back.

We need a new model. We need to force contribution, because software
corporations won't give back otherwise. I've worked for big corps and the
bureaucracy will not allow it, even if developers wish to. If we don't force
legal departments to comply we will lose the whole culture of freedom we've
built in the past 40 years.

~~~
SlowRobotAhead
>We need to force contribution

I’m interested in your proposed mechanism for that!

~~~
paulryanrogers
Perhaps they meant force contributing back improvements they're already
making. I imagine AGPL may be what they had in mind.

EDIT: fixed typo

------
jcims
Currently we wire all of our VPCs into a large network to access services, and
that brings with it all of the associated security concerns.

I wonder if moving to something like this would allow us to eliminate the
global network and let VPCs run in an isolated context save for services
published via mesh.

~~~
femto113
Look into VPC Endpoint Services, it may address your use case.

"You can create your own application in your VPC and configure it as an AWS
PrivateLink-powered service (referred to as an endpoint service). Other AWS
principals can create a connection from their VPC to your endpoint service
using an interface VPC endpoint. You are the service provider, and the AWS
principals that create connections to your service are service consumers."

[https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-
se...](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html)

~~~
jcims
Thank you, actually doing a POC of that now and to your point it's probably a
more appropriate solution to the problem. Appreciate the suggestion!

------
sbr464
Also check out Ambassador, which uses Envoy too. Friendly team and easy to
grok API.

------
etaioinshrdlu
I actually don't understand what problem this and other API gateways solve?

Let's say I have a bunch of services calling each other. Which I already do...
Why should I add this?

~~~
trpc
This is a service mesh like Istio not an API gateway, it's mainly used for
automatic and transparent service discovery and load balancing where client
and server service endpoints don't have to worry about that, also other
features are automatic handling of failure when one server endpoint isn't
responding, traffic management, securing communications between services,
enforcing L7/L4 kind of a firewall between services, telemetry, etc..., you
probably don't want to use a service mesh like this until your software
architecture gets really complex

------
sbr464
Is there a planned date when Mesh will be added to the AWS HIPAA covered
services list? Didn’t see it currently listed.

~~~
BurritoAlPastor
AWS generally doesn’t announce dates for BAA coverage ahead of time, but your
account manager may be able to give you a heads-up a couple weeks beforehand
if you ask.

~~~
sbr464
Thx, probably a common question, but service routing is a hot topic, looking
forward to the announce.

------
sbr464
Can Mesh transparently route/redirect to non-AWS URLs, without deploying
another service to handle that need?

~~~
jtoberon
Yes. An example can be found in the issue about making this simpler to set up:
[https://github.com/aws/aws-app-mesh-
roadmap/issues/2](https://github.com/aws/aws-app-mesh-roadmap/issues/2).

------
trpc
Again, AWS proves to be shamelessly exploitative of others' work and success.
This must be a culture there or something.

~~~
yjftsjthsd-h
> shamelessly exploitative of others' work and success

i.e. using open source under the published license? Look, I'd prefer that
everyone using open software supports it with public patches, but if it's not
under A/GPL or something, then clearly the authors weren't so worried about
it. If you don't like others using your work without publishing their changes,
use A/GPL. If you don't like others using your work without paying you, go
with shared source (and accept that you're writing proprietary software) or
use a noncommercial license or something. But don't publish something and then
complain that people used it under the exact terms that you published it!

------
ris
I thought AWS Xray was the non-transferrable skill that you were supposed to
pour your time into and amalgamate into your project to solve this problem.

Always space for one more I guess!

~~~
cthalupa
X-Ray is for tracing your overall application across multiple
services/components. It's more akin to New Relic and similar products.

