Netflix has built a CDN to distribute streaming media through most of the world. The content caches run a lightly customized version of the FreeBSD operating system. This presentation will describe how Netflix uses FreeBSD, and the benefits to both FreeBSD and Netflix.
About a year ago the PostgreSQL community discovered that fsync (on Linux and some BSD systems) may not work the way we always thought it is, with possibly disastrous consequences for data durability/consistency (which is something the PostgreSQL community really values).
This keynote is part history lesson and part rallying cry. Proprietary OSes and services aren't dead, they just morphed into the cloud. By remembering why Linux was important in the age of Solaris, we can apply those lessons to cloud services before their proprietary APIs and vendor lock-in risk undoing the freedom, open standards, and overall progress our community has made over the last 20 years.
In this paper we have presented Charon, a tool for provision- ing and deployment of networks of machines from declarative specifications. It has several important properties, such as reproducibility, integration of provisioning and deployment, and abstraction over cloud backends. In future work, we intend to improve management of mutable state, e.g., to allow migration of machines between cloud backends or regions.
PostgreSQL is emerging as the standard destination for database migrations from proprietary databases. As a consequence, there is an increase in demand for database side code migration and associated performance troubleshooting. One might be able to trace the latency to a plsql function, but explaining what happens within a function could be a difficult question. Things get messier when you know the function call is taking time, but within that function there are calls to other functions as part of its body. It is a very challenging question to identify which line inside a function—or block of code—is causing the slowness. In order to answer such questions, we need to know how much time an execution spends on each line or block of code. The plprofiler project provides great tooling and extensions to address such questions.
Technologists who want their ideas heard, understood, and funded are often told to speak the language of business—without really knowing what that is. This book’s toolkit provides architects, product managers, technology managers, and executives with a shared language—in the form of repeatable, practical patterns and templates—to produce great technology strategies.
The cost and performance models are two of the key drivers of the popularity of serverless and Function-as-a-Service (FaaS).
Cold starts have gone down a lot, from multiple seconds to 100s of milliseconds, but there is still much space for improvement.
There are various techniques that are being used to improve the performance of serverless functions, most of which focus on reducing or avoiding cold starts.
These optimizations are not free; it is a trade-off between performance and cost, which depends on the requirements of your application.
Currently, closed-source serverless services offered by public clouds offer few options for users to influence these trade-offs. Open-source FaaS frameworks that can run anywhere (such as Fission) offer full flexibility to tweak these performance/cost tradeoffs.
Serverless computing is not just about paying for the resources that you use; it is about only paying for the performance you actually need.
The Library of Babel is a short story by Argentine author and librarian Jorge Luis Borges, conceiving of a universe in the form of a vast library containing all possible 410-page books of a certain format and character set.
Braintree Payments uses PostgreSQL as its primary datastore. We rely heavily on the data safety and consistency guarantees a traditional relational database offers us, but these guarantees come with certain operational difficulties. To make things even more interesting, we allow zero scheduled functional downtime for our main payments processing services.
Several years ago we published a blog post detailing some of the things we had learned about how to safely run DDL (data definition language) operations without interrupting our production API traffic.
Since that time PostgreSQL has gone through quite a few major upgrade cycles — several of which have added improved support for concurrent DDL. We’ve also further refined our processes. Given how much has changed, we figured it was time for a blog post redux.