athrun

As a best practice, use a 'normal' name for your S3 bucket and then put Cloudfront in front of your S3 website.

This way you are not limited by bucket names and you also avoid any SSL validation errors.

Note: you can set Cloudfront's TTL to 0 if you don't need any caching.

And IBM has done this for a long time with its mainframes & zSeries. You can pay a fee to switch additional processors on.

I don't see why their management career would be over. Especially if they are looking at management opportunities at US companies operating in France.

This is an industry I know well and certainly some of the FR country managers of US tech companies have shady pasts. In a sales-driven organisation this is usually seen positively as some sort of war wound (ie: this is a man ready to do what's necessary).

Thanks for the correction! I was in panic mode when I found that app listed in the Task Manager, I really thought my computer had been compromised and I uninstalled that app right away without actually looking at it. Glad to know it's 'only' an ad and not arbitrary code.

But as you point out, it's still an obvious violation of trust...

Up until about two weeks ago, I thought people were being unreasonably whinny about the changes in Windows 10.

This was before I noticed that Candy Crush Saga silently installed itself on my Windows 10 machine. Not only that but it was listed as a running application in the Task Manager. Think about it: the system is silently installing & running third party apps without your consent (!) and there's no option to control that behavior. (This is not me having hallucinations, see [1] for other reports of that behavior).

I don't know why it took that long but it seriously compromised any trust I had with the company.

[1] https://www.google.ie/search?rls=en&q=windows+10+candy+crush...

I suspect API Gateway + Lambda.

I'm French and while I'm generally in favor of usage of open-source by our public offices, I'm not sure moving to LibreOffice is an achievement to be proud of.

In 2016, can an office suite claim to increase "productivity" without any Cloud-based collaboration features built-in? It seems so old school, the rest of the world is moving on and once again, our public sector is left stuck in the past.

I understand the advantages of using an open format but AFAIK both Office or Google Docs can export to ODF for long term archival if needed.

This is Gartner's famous "Magic Quadrant".

It looks like any WSGI-compatible app would work. Note that your code itself would need to work within Lambda constraints (http://docs.aws.amazon.com/lambda/latest/dg/limits.html).

They certainly already have a SDK for Unity: https://github.com/aws/aws-sdk-unity

You are comparing open-source Software against Services.

It's as if you were saying that to compete with Amazon.com (retail) you simply have to deploy Magento or Open Cart...

They are leveraging the Cross-Account access feature of the AWS Management console, which has been released early this year: https://aws.amazon.com/blogs/aws/new-cross-account-access-in...

> If you switch to ops-admin @ stage for example, and then go to the S3 page in the console,

> will you get a listing of all buckets in the stage AWS account even though your login

> session as calvin "belongs" to an other AWS account (segment)?

It should work like that, yes. Your privileges will be "scoped" to the role you are assuming in the "stage" account.

> I can see how having separate AWS accounts for dev/stage/prod makes things easier.

It's also a good way of maintaining agility when you have multiple teams working in parallel on different projects (ex: 1 team = 1 AWS account). Zalando has recently published a bunch of tools leveraging IAM to help manage multiple AWS accounts (ex: federated SSH access) : https://stups.io/

I think the main advantage here is that it's a one-binary-file webserver. Very simple to install and ideal for file sharing among coworkers or similar situations. A modern equivalent of "python -m SimpleHTTPServer".

Sounds very interesting! I will be waiting for the blog post :)

"you shouldn't expect your code to block on disk io"

uh?! In what world are you living in? Blocking the main thread of your app on disk I/O makes for a poor user experience.

Disk I/O is a big deal for a whole range of applications. I would even say almost all apps have to deal with disk I/O at some point, as opposed to network I/O.

I don't see how a single "skilled ops person" can deliver "lower service fees, more flexibility, improved productivity". On the other hand, Cloud Computing will, by definition, let you turn on and off services based on business demands. It doesn't get much more flexible and cost effective than that.

"You just need to be better off, long term." - This is a good one. Do you really think your homegrown Docker environment, Hadoop cluster and/or state-of-the-art Cassandra ring maintained by your one and only skilled Unicorn is a better long term plan than 100% managed alternatives? Let's see how well (and how secure) your in-house stuff work 2-3 years down the road and how it will then compare with the always "up-to-date" alternative.

The "vendor lock-in" part is your only valid argument, in my opinion. Costs/benefits will have be weighted properly. How much do you value business agility and pace of innovation vs. increased vendor dependency?

The proper answer will be different for all businesses, but I would argue that as long as a specific IT component/technology is not part of your core business, you might be better off buying it off-the-shelves instead of building it and maintaining it yourself.

"Once you can afford to hire competent Ops staff"

Here, that's the catch. Most companies simply can't. Competing against Amazon, Microsoft and Google for talent doesn't sound like a smart strategy.

Have you seen this? https://forums.aws.amazon.com/thread.jspa?messageID=673863

It's a mapping template for the AWS API Gateway you can use to convert both HTML form POSTed data and HTTP GET query string data to JSON.

Automating large server farms is a very different job from being an Independent Software Vendor (ISV).

One difference is that as an ISV you don't have a lot of control on the way the system is setup, you have to start with assumptions and then work from there. -> Your job is to make your software work on fragile systems.

When you are dealing with managing systems at scale, hopefully you know exactly what you're dealing with. You don't have to make assumptions, you _control_ what components are on each box. -> Your job is to make your systems run broken apps :)

I disagree. You're referencing to specific _tools_ being used as a de facto standard and this is certainly true to some extent.

However, the incompatibilities come from how these tools are configured: there are numerous ways of interfacing/configuring X.org, syslog, networking and wireless tools, etc. Generally each distribution comes up with its "own true way" of doing it. This introduces a lot a pain for anyone trying to come up with a generic way of working with underlying subsystems. It's not impossible but it takes a lot of effort, is very fragile and needs an ongoing maintenance to keep up with the changes introduced by the distributions.

My point is that systemd exposes a set of capabilities and known interfaces you can rely on being there. This is far from being enough but it still an improvement in my eyes.

Binary compatibility is certainly a major issue but I think you are downplaying the compatibility headaches introduced by the way each distributions are solving the same issues with slightly different methods. I'm thinking of: logging, default character sets, locale, timezones, mount points & encrypted block storage, basic OS versioning information, networking, service management, networking. And I'm forgetting a plethora of others areas. There were/are attempts to have standardization around some this, like the FHS or the LSB for example. But it's hard to argue that systemd was far more successful into bringing a semblance of order than any past attempts. There's still a long way to go.

The general lack of compatibility between distributions usually leads software publishers to packaging and testing only one or two versions of their software. The community will then try to repackage it for other distributions. When the apps are not 100% open-source, it usually leads to huge delays for updates and broken packages after a while.

What would prevent you from using this API Gateway as a proxy to your Lambda functions? It would work just fine for request/response use-cases.

The blog post mentions that you can describe your API using Swagger and then import that. I suppose it means you can keep your Swagger definitions under version control.

IMHO, it's best to see Empire/Deis/Dokku/etc. as a mean to an end, not the end itself.

While Empire itself may be tied to AWS, your app is still a portable, 12-factor, Heroku-compatible app. You can run it elsewhere.

The first comment below the article points to an interview by Brian Robertson (Holocracy author) which discuss precisely this irony: https://www.youtube.com/watch?v=DOpVJIQWgqk

In traditional organizations, ultimate power comes from the top so implementing a large scale change requires a heavy handed top down approach.

I think DynamoDB has replaced SimpleDB as the default key-value store if you're running within AWS.

For example, even the official Kinesis Client Library will store its state in a DynamoDB table. (link: http://docs.aws.amazon.com/kinesis/latest/dev/kinesis-record...)

DynamoDB is quite inexpensive at low usage levels. The Free Tier gives you: "25 GB of Storage, 25 Units of Read Capacity and 25 Units of Write Capacity – Enough to handle up to 200M requests per month"

DynamoDB's free tier doesn't expire after 12 months. (Source: http://aws.amazon.com/free/)

The bandwidth between AWS regions and Cloudfront is free so you can save a lot here as well while improving performance for your end users. And on the Cloudfront side, you can negotiate pricing to further reduce the cost.

Edit with Source: Cloudfront pricing page: http://aws.amazon.com/cloudfront/pricing/

"If you are using an AWS origin, effective December 1, 2014, data transferred from origin to edge locations (Amazon CloudFront "origin fetches") will be free of charge."

You're right. And considering they have just added Cognito support to their Node.js SDK, we can suppose this is the master plan. http://aws.amazon.com/releasenotes/JavaScript/99205414836272...

Why is EBS out of the question? Do you have an horror story to share? :)

I agree there are some specific uses cases ideally suited for ephemeral storage. But in most cases EBS gives you quicker provisioning times, snapshotting and of course persistance. In the past, performance and reliability sucked but AFAIK this is not an issue anymore, especially with the new General Purpose (SSD backed) EBS volumes.