Recently at work, at SNCF Connect & Tech,
we needed to expose some static documents as HTTP endpoints:
a GET /version that would provide some information about the application version as JSON,
and a GET /openapi/yaml that would return the OpenAPI 3 specification of our HTTP API as YAML.
We …
In the end, we found that the maximum connections concept was too imprecise to provide the complete answer to the puzzle. In this article, we’ll describe other approaches such as load shedding that we found worked well.
With traffic profiles where requests arrive in at periodic intervals, and a low total amount of requests, serverless architecture seems to be a great architecture in terms of cost, speed of delivery and effort. Thus, Lambda is probably the way to go if our application has sufficiently large periods of inactivity. Once the break-even point is reached, when EC2 is more cost-effective than Lambda, the cost difference grows rapidly, making Lambda less and less attractive in terms of cost. Thus, it is of great importance to know if the expected amount of traffic will be around the break-even point. Be aware of the CPU throttling you will get with the smaller memory flavors of Lambda. If your code is CPU-bound, choosing the smaller memory flavors might not be an option, since execution times, and thus latency, might grow beyond your requirements. On the other hand, if your code is I/O bound, the CPU throttling might not affect you significantly. Break-even point (if there is one, that is) strongly depends on the application itself. Without measuring the target application code, knowing the intended usage of the service, the SLA and the capabilities of the team in charge of building the application it is almost impossible to know for sure which service, Lambda or EC2, is more convenient.
Chalice , a Python Serverless Microframework developed by AWS, enables you to quickly spin up and deploy a working serverless app that scales up and down on its own as required using AWS Lambda.
tl;dr :
- Start using [your software] in production in a non-critical capacity (by sending a small percentage of traffic to it, on a less critical service, etc)
- try to have each incident only once
- Understand what is ok to break and isn’t
For example, with Kubernetes:
- ok to break:
- any stateless control plane component can crash or be cycled out or go down for 5 minutes at any time
- kubernetes networking can break as much as it wants because we decided not to use it to start
- not ok to break
- for us, if etcd goes down for 10 minutes, that’s ok
- containers not starting or crashing on startup
- containers not having access to the resources they need
- pods being terminated unexpectedly by Kubernetes
With Envoy, the breakdown is pretty different:
You use it like this:
$ scarr init -domain falafel.exposed -name falafelexposed
Initializing...done
$ cd falafelexposed
$ vim scarr.yml # Edit a few fields here
$ echo "<html>The deadly secret of falafel</html>" > index.html
$ AWS_PROFILE=scarr scarr deploy
... a bunch of aws stuff happens automatically ...
$ curl https://falafel.exposed
<html>The deadly secret of falafel</html>What it's doing under the hood is:
- Registers the given domain through route53 (prompts to confirm this)
- Creates a TLS certificate through ACM
- Uses route53 DNS to validate that certificate
- Creates an S3 bucket
- Creates a Cloudfront distribution pointed to that S3 bucket using the ACM certificate
- Creates an apex dns record pointing to that Cloudfront
- Syncs the current directory to that S3 bucket and invalidates the Cloudfront cache.
we operate Kubernetes as follows to try and minimise it:
- We run multiple production clusters and teams are able to choose which clusters to run their application in. We don’t use Federation yet (we’re waiting on AWS support) but we use Envoy instead to load-balance across the different cluster Ingress load-balancers. We can automate much of this with our Continuous Delivery pipeline (we use Drone) and other AWS services.
- All clusters are configured with the same Namespaces. These map approximately 1:1 with teams.
- We use RBAC to control access to Namespaces. All access is authenticated and authorised against our corporate identity in Active Directory.
- Clusters are auto-scaled and we do as much as we can to optimise node start-up time.
- Applications auto-scale using application-level metrics exported from Prometheus.
Not very insightful, but I'm retaining some quotes:
But IT operations includes much more than the limited “ops” functions we typically fold into a DevOps team. I’m talking about things like ticket management, incident handling, user management and authorization, backups and recovery, network management, security operations, infrastructure procurement and cost optimization, compliance reporting, and much more. In today’s IT organization, where do these responsibilities fall?
You want DevOps teams to have a streamlined, low lead-time, lean pipeline to production. Devoting team capacity to this broader set of operational functions may slow down this pipeline. There are also efficiencies to be gained by sharing these practices across the work of all the DevOps teams.
All of this is to say that a portion of IT operations still exists independently of the DevOps teams, performing those “ops” functions that are not in “DevOps” while the DevOps teams focus on that subset of ops functions specifically related to deploying code and responding to code-related incidents
Des serveurs d’Amazon jusqu’aux machines rouges installées directement chez les fournisseurs d’accès à internet, la firme a créé au fil des années un système complexe, mais d’une efficacité redoutable, le tout à un prix très raisonnable qui lui donne un avantage concurrentiel évident.
This page helps you find and compare AWS EC2 instance types, features and pricing. The data is provided by AWSPrice List API.
manage groups of collaborators and associate each private repo with one of those groups + enable all of your contributors to manage who is and isn't a collaborator.
Example of project combining:
- Github API usage & its AWS SNS integration
- AWS Lambda written in Python
A vault for securely storing and accessing AWS credentials in development environments
Easy to use tool that automatically replaces some or even all on-demand AutoScaling group members with similar or larger identically configured spot instances in order to generate significant cost savings on AWS EC2, behaving much like an AutoScaling-backed spot fleet
Comparison of: disk, network, compute, support, failures, billing, cost, security, monitoring...
VIA: http://taint.org
editor of encrypted files that supports YAML, JSON and BINARY formats and encrypts with AWS KMS and PGP