There was a Fargate one at 3:45 and a CI/CD one at 5 that were pretty interesting.

IME you always pick up stuff from those conferences even if you don't realize it. You see how people are using things, how they talk about it, etc. At least the first one in a new subject matter. My second node summit was pretty boring.

For example: Holy mother does AWS have a lot of products (125) and do a lot of things. I think I learned something about most of them today - at least a few sentence synopsis of what they do. My head is still spinning.

Can you imagine that code base that runs all that, keeps track of billing, etc?

Serverless or almost serverless is absolutely a whole new world from the environment I've been developing in the last 20 years. 5 years ago it was completely different. Imagine how much different it will be in 5 years? Like there might just be one service, you upload your blob of code and it figures everything out.

This is what programming to browsers was like in the early days. Or mobile apps. Everything changed so fast.

And holy **** is the vendor lockin for AWS gonna be a nightmare. It will make the current Oracle situation so many companies are stuck in look like a parking ticket. But YOLO - not my problem. I bet Amazon becomes the first $2 trillion company.

For me and one member of my team who is pretty savvy to the inner workings of this business it was pretty depressing. We saw one booth there that did exactly what we aspire to be with our new product, and they did it better than we can.

This shift to this kind of cloud infrastructure really goes against what we're trying to build and sell. Sucks tbh. Oh well.

Well when vendor lockin kicks in you will be there to lure them back off AWS. Just hang around 10-20 years.

Can't get any sanctification. When I write C++, I complain why didn't choose a higher level language to make my life (and potential readers') easier. When I write Ruby, I worry about how much performance I'm sacrificing. Java isn't for me, and I don't feel like investing time learning a new language (e.g. Go) unless it's super popular. #Rant #Moody

Stop ranting and learn Go. You won't regret it.

I should look at Go again, last time I did it was a bit of a toy language - I believe you could not link other libraries too it and there was not a lot of native go stuff. I like the language syntax though, and it was pretty fast as stuff it could do.

If its just a booth from a non-Amazon company, I wouldn't be too depressed. I've talked to a whole lot of vendors at conferences and at least half are full of ****. No real demos and blatantly promising functionality that doesn't exist or contradicts their own website.

But if your business depends on people not going to the cloud at the infrastructure level... you're fighting a big uphill battle (and in all honesty will probably lose). There are a lot of good reasons the cloud makes sense, and even if "the Next Big Thing" in 10-20 years is different, it almost certainly won't look anything at all like the model where companies run their own data centers and buy software.


I don't think the vendor lock-in is going to be quite that bad. Google and Microsoft are growing fast. You're even starting to hear more about Alibaba Cloud - which is probably one of the first that I think can actually gain a non-trivial chunk of the market.

Amazon also has a lot of the first-mover problems where they're now dealing with legacy code/constraints that GCP and Azure can address right from the start. GCP at least (I don't have any experience with Azure) also knows that the secret to stealing AWS's business is to make that transition pretty seamless. So something like GCS (the Google equivalent to S3) has a completely compatible API to s3. Many major libraries can switch between the two cloud storages seamlessly.

I don't think AWS will ever get to the point where they can start making massive margins without fear of people leaving. Although who knows...

That being said, my one investing regret is not putting a whole bunch of money in Amazon before the broke out AWS. It was pretty clear AWS was going to be massive and a lot of non-tech people didn't really get the real scale/importance of it and were focusing just on their retail business. But I got convinced to stick with index funds... and here I am.

You really think Alibaba cloud can take significant market share from AWS? I would think that given the Chinese government's actions and Chinese business practices in general would be a major detriment to gaining traction outside of China.

China is a big market. So just being the cloud of choice there is going to get you far.

There's also a big chunk of the world that views the US Government and business practices in the same light. And in some of those places they actually view China more favorably.

My understanding is that a lot of the increased market share here is driven by (and will continue to be driven by) new businesses and people migrating away from legacy systems like data centers. So there's no need to steal customers at this point, just convince people they should start with you. I think Alibaba will be able to get some non-trivial share by doing that.

And I mean in this in the sense of a cloud provider that offers more than just pure infrastructure or a small number of hosted services. AWS, GCP, and Azure are trying to build the one-stop "build a cloud company" ecosystem with compute, storage, messaging, analytics, etc. services.

I freely admit I don't know much about Alibaba though. I've just started hearing it come up more often.

Yeah hosting is obviously very portable. But if you start using a bunch of the other 125 services and integrating them together - as my boss wants us to do - I bet things get real sticky real fast.

You can link it to C/C++ stuff now (though for cpp, you have to make a straight C interface to anything you'd call from Go) and I think open source support for it has grown massively.

Without actually counting, I'd guess about half the services offered have really simple copyable APIs (like s3) or are hosted versions of open source software. Our rule of thumb was that it was generally fine to use any of these since if you needed to you could pretty easily move to an alternative provider or run it yourself.

The other half, they definitely feel like you're committing yourself to some pretty hardcore lock-in.

Like lambda?

I don't know much about lambda, but yeah I assume that's pretty much AWS specific unless the code is able to be written in a generic way - in which case I assume other providers could offer alternatives pretty easily.

The code itself is pretty generic (at least from the node code I've seen), but the orchestration and communication between lambdas could become pretty sticky.

Is anyone here doing microservices and if so how do you handle MS to MS communication? Some possible strategies include:

1. Straight REST homey. Let any MS talk to any other MS. Devs can figure out strategies to manage dependency complexity or authorization.
2. REST with some kind of service mesh like kinerd or istio to wrangle connectivity issues.
3. Pub/sub with something like NATS. Maybe something like AWS step functions to handle the async nature and keep dependencies explicit.
4. Avoid communications at all costs, find another way by persisting data and polling or something (which is still a dependency). Or just say if things need to communicate they live in the same app.

Other?

I tend to like #3 in general. But it feels like the wrong solution for the typical case of one MS needing information from another MS. Why should this be async, especially if there's an end user waiting on the result? Not that the timing matters much. But you're basically forcing a synchronous business process into a two step async process.

Yeah, that's why I think it's probably time to check it out again. I leverage a lot of existing libraries in stuff I do.

I continously try to get into go and I just cannot make it stick. I love their concurrency model but as soon as boots hit the road and I'm writing code, I hate my life. Feels like everything is just way too manual and I immediately realize I could do it in any other Lang way faster. Frustrating mostly because everyone seems to love it We run the whole gambit. Rest, grpc, pub sub using sns on aws.

I'd stick to rest to open. Grpc was premature optimization and pub sub is more just to help with an event driven system rewrite due to scale.

The real debate for me is always client libs for each MS or just each MS manually calling the rest end points. We mix and match where I work depending on logic needed in a client lib (like caching)

I like the client lib approach, esp if you're all in one language. We're at a ****ty point where we have to write a client lib in 2-5 languages

Service mesh can replace those kind of low-level client libs apparently. https://thenewstack.io/which-service-mesh-should-i-use/

But even w/o that I'm 100% about client libs, even for a lot of higher level stuff. I don't want devs reinventing wheels and creating 100 unique snowflakes that do similar things in different ways. In any big system that sticks around for a while, you will always need to implement new cross-cutting concerns as requirements evolve and mutate. You can't do that if your only system-level hooks exist completely outside the MS code itself.

So I'm also thinking more about app-level architecture and governance. At a dependency-tracking level - a giant web of REST calls gets really hard to manage when you get to dozens of microservices and super-crazy with 100s.

At least if all that was in a Java app you could see all those flows and dependencies in a sequence diagram or stack trace. With microservices you have to write your own trackers if you want to visualize the web of dependencies in one place.

However with something like async and step functions at least you have one place to go to see any MS to MS dependencies (the step function library). And of course pub/sub is fundamentally much more loosely coupled. Which generally makes it easier to test each MS in isolation.

I'm not as worried about REST vs. GRPC right now because they're both synchronous which makes them fundamentally similar - and easier to write adapters I'm assuming.

In terms of stupid complaining about learning new languages. For all ththe python code I'm writing I just keep getting frustrated I can write the equivalent JS from memory but I have to admit the syntax and library seems way easier.

Sometimes when I’m really tired i write a rough draft/POC of an idea in a language i’m familiar with, get it working, then rewrite it in what it’s supposed to be later.

Terrible practice i will eventually breakbut I feel like I probably gain some time that would be fumbling around with syntax and google when I really just want to be implementing my idea.

I love learning new syntaxes. I feel like I could have written a computer language if I had the ambition and desire to lock myself in my room for 2 years. Learning syntax was my favorite part of Spanish too.

What I don't like is learning new tools. So yeah modern front-end web development is a blast for me.

At the node school I mentored at I got to overhear an hour-long super-deep dive conversation about all the crazy things they were doing with webpack. Just ****ing shoot me if that's ever my job.

Just gimme a hammer, saw and screwdriver and let me go build something. Drill? What's a drill? **** you, I don't need that.

https://medium.com/@pistacchio/i-m-a...ys-fb5c50917df

Check out x Ray on aws. It traces calls between all your services and provides maps and logging for it. It's how we debugger out last issue between 3 services communication breaking down

Re: service mesh. Takes a long time to implement. We had istio and it was breaking down with 4 people workiny on it 24/7

A good example of a client lib is we have an internal oauth server that generates intra service communication tokens. People were literally making rest calls to it and then caching the token however they wanted for however long they wanted. Perfect spot for a client lib that dictates all that. Now they write 2-5 lines and it works flawlessly

Yeah for sure. We had client libs for a lot of that stuff at my old job. Like I'll enforce a lot more than that to go through client libs if I can.

I might do what I did in our old monster node app - literally abstract out the entire rest call and just giv devs a declarative JSON object where they can specify service name, verb, headers, params, payload, etc. - and synchronous methods for pre and post processing. I want system level hooks and I don't want snowflakes.

Good to know about the service mesh.