Using Lambda functions stored in ECR has no impact on performance from my experience. AWS Lambda uses Firecracker under the hood, which builds a VM from a container image. It's likely that non-ECR image based Lambdas are actually packaged as a container image before being launched into a Firecracker VM.
What’s more interesting to me than the NPS scores are the free form comment section below the 0-10 rating.
Never mind that anything below X is considered neutral or a detractor. You asked a user / customer/ etc to rate you on a scale of 1-10 and then tell you why.
Want to know what you’re truly screwing up on? Take the feedback on your 1-6 scores seriously and you can find the low hanging fruit to take a product from mediocre to a great user experience.
That’s the true NPS value. It’s all about how you handle the feedback.
The same functionality could have been accomplished by just allowing us to specify the max number of concurrent instances of a function that can be active at a time. With proper request queuing the problem would be solved. As usual, AWS solves a problem they failed to design for by charging for an overly complex solution. Flame me if you want but there are K8s serverless frameworks that address this out of the box.
Oh the "service bus" <strike>xml</strike> json is coming back... its called lambda architecture.
And again nothing new except someone else takes care of some server software for you with the promise of reduced price and maintenance but the reality eventually becomes tight proprietary coupling and eventual price gauging.
Amazon's own Lambda is that, yes. But the Lambda architecture it inspired is the opposite: a de-facto standard (based on the way Amazon's works, but probably eventually an open standard) for servers any org can use to stand up their own public or private FaaS cloud, which developers can deploy Lambda functions onto rather than having to build an entire container/VM just to slot it into OpenStack.
I doubt it will ever be a standard. Amazon loves vendor lock in. Plus most of the cloud services love to do their own thing for each service type. The main exception seems to be Kubernetes. Google has it in GCE, and Amazon has said they are working on their own Kubernetes service. If that happens, I bet Azure will follow if they aren't already working on it.
I (and others) are not so much imagining a standard between cloud vendors, as we're imagining a standard "FaaS server function API" (sort of like how the web has a standard DOM API) supported by several FOSS FaaS server implementations (sort of like how the web has several FOSS Javascript engines.)
Given such a standard API and compatible servers, you'd then deploy a FaaS server cluster to your public/private cloud of choice, the same way you deploy e.g. a Kubernetes cluster, or a Riak cluster.
There would likely by small public clouds attempting to be "FaaS native" by exposing only such servers in a multitenant configuration (like small public clouds like Hyper are currently doing with CaaS.) Their implementations wouldn't always be exactly compatible, and might have some lock-in.
However, once FaaS "caught on" with the enterprise, a FaaS server would likely make its way into the OpenStack architecture.
At that point, you'd see medium-sized public cloud providers like OVH and DigitalOcean set up their own multitenant FaaS clusters as well, probably with custom code, but built to be compatible with the OpenStack FaaS tooling, to allow enterprises the freedom to move FaaS functions freely between public and private clouds.
And, eventually, the other major cloud providers would feel the need to support the API.
---
This path has already been followed: it's what happened to Amazon S3—first cloned (but not compatibly) in FOSS by tools like Riak CS; then standardized by OpenStack Swift; then cloned compatibly in FOSS by tools like Minio; then picked up by medium-scale clouds like Rackspace; and then, eventually, picked up by Azure and GCP as secondary APIs to address their equivalent offerings (that originally had quite different APIs.)
You can definitely do microservices that way but in reality they tend to be more granular both functionality wise and density-wise.
With old skool SOA you'd typically have a monolith app with a bunch of endpoints. With microservices, especially in a containerized environment they tend to be more lightweight.
Microservices is just SOA rebranded for the cool kids. The fact that modern orchestration and tooling makes it easier to have more granular services changes the equation for how you factor the services, to be sure, but it's an evolution not a revolution.
> Programming in C/C++, Java, Javascript, that's easy, anyone can write code. But having the skill of standing in a circle and saying what you've been working on, what you will be working on, and if you have any blockers, that takes pure talent.
I'd have to say Google's Tools are 100x better than they used to be. Android Studio is based on IntelliJ IDEA and they've done a decent job of getting emulator performance where it needs to be on good hardware.
That being said, I think Swift was a huge win to Apple developers who were unhappy with Objective-C. Xcode and the iOS simulator are still way ahead of Google's tools on performance.
On SDKs:
This is where Google is really blowing it and where Apple shines. Apple's SDKs tend to be well thought out and well documented.
Android's SDKs on the other hand are poorly documented and are fragmented into a mess. To expand a bit, there are new SDKs for new features on new hardware and tons of "compatibility" SDKs that have to be used to bring modern features to your app if you want to support old Android releases (you have to).
Android's SDKs show both a lack of direction and a rush to patch up the fragmentation mess. This isn't a knock at their hardware (Pixel, etc), which looks nice. There's just a general lack of coherency among their APIs and no clear path on how they're going to fix it.
TLDR;
It's fair to say Google is making progress making their developer's lives better but Apple (and it's community developed SDKs) still make a better developer platform and a better software to develop with.
As an US citizen, I no longer salute that piece of cloth or sing the national anthem at sports games. I don't even bother standing for it and encourage others to do the same to show our distaste for how our own government treats us.
I was disgusted in the 2000's when being against the Iraq war was not only being flaunted unpatriotic but not supporting our troops. That's BS. I support our troops and would rather not have seen them deployed to conduct Cheney's bidding.
I will sign the petition and if some asshole gives me trouble at the border for it, so what? I'm a US citizen and entitled to re-enter my country. F them.
"If patriotism is 'the last refuge of a scoundrel,' it is not merely because evil deeds may be performed in the name of patriotism, but because patriotic fervor can obliterate moral distinctions altogether”
~ Ralph B. Perry
> I will sign the petition and if some asshole gives me trouble at the border for it, so what? I'm a US citizen and entitled to re-enter my country. F them.
I posted this reply earlier too, but figured I'd respond here also. The US government has, in the past, refused entry to US citizens. They do this not at the border, but at the foreign airport. Say you fly to Germany, and then try to come back. They'll tell the airline to refuse to board you, and then you're stuck there. Sure, if you managed to somehow reach a US land border, they would have to allow you in (after a lengthy interrogation, I imagine). But that's not very practical or economical.
That's exactly right, here's a real-world example:
But the worst cases are those like Long's: when the person is suddenly barred from flying when they are outside of the US, often on the other side of the world. As a practical matter, that government act effectively exiles them from their own country. "Obviously, I can't get to Oklahoma from Qatar if I can't fly," said Long. "Trying to take a boat would take weeks away from work just for the travel alone, and it's not affordable. If I can't fly, then I can't go back home."
This is most probably because no-fly list is a pile of steaming crap, they had Senators, Congressmen, military veterans, toddlers, etc. on the list. 99.99% it has nothing to do with this specific person (though of course not being a Senator, but being a Muslim from Qatar doesn't exactly help). It's not targeting, it's the opposite.
I'm not sure though why he couldn't fly to Mexico instead - is DHS no-fly list mandatory for other countries?
> As an US citizen, I no longer salute that piece of cloth or sing the national anthem at sports games. I don't even bother standing for it and encourage others to do the same to show our distaste for how our own government treats us.
The fact that you can do this and face no consequences says something about our freedoms though. At the very least we have a foundation that is worth taking the effort to improve.
"I'm a US citizen and entitled to re-enter my country"
they think otherwise. they rightfully own you and can do whatever they please with you. feel free to try to prove me wrong and not to sound like minuteman.
Gave this a quick look. I'm much more a fan of Spring Boot (http://projects.spring.io/spring-boot/). Like Pippo, Spring Boot starts with a lot of auto-configured defaults that can get you off the ground quickly. However, the full power of Spring and its related projects are at your fingertips and you can reduce the amount of auto-configuration as your project becomes more complex. Also like Spring's stereotype principles more than extending a base "Controller" (in Spring, you annotate a POJO with @Controller or @RestController).
As mentioned previously, JAX-RS really shines for micro services. The same interfaces can be shared between client and server, making client development a breeze. Spring Boot supports JAX-RS services as well via a Jersey adapter.
Same as any other code--via debug step-through, or logging, centered on the code that processes the annotations. It's actually much saner than heaps of "marker interfaces" and is readily testable.
https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...