From fc4acb6d68d3d4c3a88fc71c985f76bd74b6d4c1 Mon Sep 17 00:00:00 2001 From: lucperkins Date: Mon, 9 Mar 2020 16:33:51 -0700 Subject: [PATCH] Begin cleaning up blog posts Signed-off-by: lucperkins --- content/blog/2015-10-26-principles.html | 27 ------- content/blog/2015-9-8-principles.html | 48 ------------ content/blog/2017-09-14-meetup-kit.html | 12 --- content/blog/beta-release.md | 20 +++++ .../blog/{2016-5-9-coreos.md => coreos.md} | 6 +- ...c-dotnet-build.md => grpc-dotnet-build.md} | 6 +- ...on-dotnetcore.md => grpc-on-dotnetcore.md} | 6 +- ...16-4-4-installation.md => installation.md} | 17 ++-- content/blog/meetup-kit.md | 11 +++ content/blog/principles.md | 77 +++++++++++++++++++ .../blog/{2016-3-24-pubsub.md => pubsub.md} | 0 .../{2016-07-25-vendasta.md => vendasta.md} | 5 +- layouts/partials/blog/hero.html | 8 +- 13 files changed, 131 insertions(+), 112 deletions(-) delete mode 100644 content/blog/2015-10-26-principles.html delete mode 100644 content/blog/2015-9-8-principles.html delete mode 100644 content/blog/2017-09-14-meetup-kit.html create mode 100644 content/blog/beta-release.md rename content/blog/{2016-5-9-coreos.md => coreos.md} (98%) rename content/blog/{2018-12-18-grpc-dotnet-build.md => grpc-dotnet-build.md} (99%) rename content/blog/{2019-09-23-grpc-on-dotnetcore.md => grpc-on-dotnetcore.md} (98%) rename content/blog/{2016-4-4-installation.md => installation.md} (67%) create mode 100644 content/blog/meetup-kit.md create mode 100644 content/blog/principles.md rename content/blog/{2016-3-24-pubsub.md => pubsub.md} (100%) rename content/blog/{2016-07-25-vendasta.md => vendasta.md} (99%) diff --git a/content/blog/2015-10-26-principles.html b/content/blog/2015-10-26-principles.html deleted file mode 100644 index d2afe82..0000000 --- a/content/blog/2015-10-26-principles.html +++ /dev/null @@ -1,27 +0,0 @@ ---- -attribution: Mugur Marculescu, gRPC -date: "2015-10-26T00:00:00Z" -published: true -title: gRPC releases Beta, opening door for use in production environments. -url: blog/beta_release ---- - -

- The gRPC team is excited to announce the immediate availability of gRPC Beta. This release marks an important point in API stability and going forward most API changes are expected to be additive in nature. This milestone opens the door for gRPC use in production environments. -

- -

- We’re also taking a big step forward in improving the installation process. Over the past few weeks we’ve rolled out gRPC packages to Debian Stable/Backports. Installation in most cases is now a two line install using the Debian package and available language specific package managers (maven, pip, gem, composer, pecl, npm, nuget, pod). In addition gRPC docker images are now available on Docker Hub. -

-

- We’ve updated the documentation on grpc.io to reflect the latest changes and released additional language-specific reference docs. See what’s changed with the Beta release in the release notes on GitHub for Java, Go and all other languages. -

-

- In keeping in line with our principles and goal to enable highly performant and scalable APIs and microservices on top of HTTP/2, in the coming months, the focus of the gRPC project will be to keep improving performance and stability and adding carefully chosen features for production use cases. Documentation will also be clarified and will continue to improve with new examples and guides. -

-

- We’ve been very excited to see the community response to gRPC and the various projects starting to use it (etcd v3 experimental api, grpc-gateway for RESTful APIs and others). -

-

- We really want to thank everyone who contributed code, gave presentations, adopted the technology and engaged in the community. With your help support we look forward to the 1.0! -

diff --git a/content/blog/2015-9-8-principles.html b/content/blog/2015-9-8-principles.html deleted file mode 100644 index 4dd51a5..0000000 --- a/content/blog/2015-9-8-principles.html +++ /dev/null @@ -1,48 +0,0 @@ ---- -attribution: Originally written by Louis Ryan with help from others at Google. -date: "2015-09-08T00:00:00Z" -published: true -title: gRPC Motivation and Design Principles. -url: blog/principles ---- - -

Motivation

- -

Google has been using a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across our data centers for over a decade. Our internal systems have long embraced the microservice architecture gaining popularity today. Having a uniform, cross-platform RPC infrastructure has allowed for the rollout of fleet-wide improvements in efficiency, security, reliability and behavioral analysis critical to supporting the incredible growth seen in that period. -

- -

Stubby has many great features - however, it's not based on any standard and is too tightly coupled to our internal infrastructure to be considered suitable for public release. With the advent of SPDY, HTTP/2, and QUIC, many of these same features have appeared in public standards, together with other features that Stubby does not provide. It became clear that it was time to rework Stubby to take advantage of this standardization, and to extend its applicability to mobile, IoT, and Cloud use-cases.

- -

Principles & Requirements

- -

Services not Objects, Messages not References - Promote the microservices design philosophy of coarse-grained message exchange between systems while avoiding the pitfalls of distributed objects and the fallacies of ignoring the network.

- -

Coverage & Simplicity - The stack should be available on every popular development platform and easy for someone to build for their platform of choice. It should be viable on CPU & memory limited devices.

- -

Free & Open - Make the fundamental features free for all to use. Release all artifacts as open-source efforts with licensing that should facilitate and not impede adoption.

- -

Interoperability & Reach - The wire-protocol must be capable of surviving traversal over common internet infrastructure.

- -

General Purpose & Performant - The stack should be applicable to a broad class of use-cases while sacrificing little in performance when compared to a use-case specific stack.

- -

Layered - Key facets of the stack must be able to evolve independently. A revision to the wire-format should not disrupt application layer bindings.

- -

Payload Agnostic - Different services need to use different message types and encodings such as protocol buffers, JSON, XML, and Thrift; the protocol and implementations must allow for this. Similarly the need for payload compression varies by use-case and payload type: the protocol should allow for pluggable compression mechanisms.

- -

Streaming - Storage systems rely on streaming and flow-control to express large data-sets. Other services, like voice-to-text or stock-tickers, rely on streaming to represent temporally related message sequences.

- -

Blocking & Non-Blocking - Support both asynchronous and synchronous processing of the sequence of messages exchanged by a client and server. This is critical for scaling and handling streams on certain platforms.

- -

Cancellation & Timeout - Operations can be expensive and long-lived - cancellation allows servers to reclaim resources when clients are well-behaved. When a causal-chain of work is tracked, cancellation can cascade. A client may indicate a timeout for a call, which allows services to tune their behavior to the needs of the client.

- -

Lameducking - Servers must be allowed to gracefully shut-down by rejecting new requests while continuing to process in-flight ones.

- -

Flow-Control - Computing power and network capacity are often unbalanced between client & server. Flow control allows for better buffer management as well as providing protection from DOS by an overly active peer.

- -

Pluggable - A wire protocol is only part of a functioning API infrastructure. Large distributed systems need security, health-checking, load-balancing and failover, monitoring, tracing, logging, and so on. Implementations should provide extensions points to allow for plugging in these features and, where useful, default implementations.

- -

Extensions as APIs - Extensions that require collaboration among services should favor using APIs rather than protocol extensions where possible. Extensions of this type could include health-checking, service introspection, load monitoring, and load-balancing assignment.

- -

Metadata Exchange - Common cross-cutting concerns like authentication or tracing rely on the exchange of data that is not part of the declared interface of a service. Deployments rely on their ability to evolve these features at a different rate to the individual APIs exposed by services.

- -

Standardized Status Codes - Clients typically respond to errors returned by API calls in a limited number of ways. The status code namespace should be constrained to make these error handling decisions clearer. If richer domain-specific status is needed the metadata exchange mechanism can be used to provide that.

diff --git a/content/blog/2017-09-14-meetup-kit.html b/content/blog/2017-09-14-meetup-kit.html deleted file mode 100644 index c6ce63e..0000000 --- a/content/blog/2017-09-14-meetup-kit.html +++ /dev/null @@ -1,12 +0,0 @@ ---- -attribution: Mark Mandel, Sandeep Dinesh -date: "2017-09-14T00:00:00Z" -published: true -title: The gRPC Meetup Kit -url: blog/meetup-kit ---- - -

If you have ever wanted to run an event around gRPC, but didn’t know where to start, or wasn’t sure what content is available - we have released the gRPC Meetup Kit!

- -

The meetup kit includes a 15 minute presentation on the basic concepts of gRPC, with accompanying slides and video for either reference or playback, as well as a 45 minute codelab that takes you through the basics of gRPC in Node.js and Go. At the end of the codelab participants will have a solid understanding of the fundamentals of gRPC.

-

If you are thinking about running a gRPC event, make sure to contact us to receive gRPC stickers and/or organise office hours over Hangouts with the gRPC team!

diff --git a/content/blog/beta-release.md b/content/blog/beta-release.md new file mode 100644 index 0000000..84281c8 --- /dev/null +++ b/content/blog/beta-release.md @@ -0,0 +1,20 @@ +--- +title: gRPC releases Beta, opening door for use in production environments +attribution: Mugur Marculescu, gRPC +date: "2015-10-26" +aliases: ["blog/beta_release"] +--- + +The gRPC team is excited to announce the immediate availability of gRPC Beta. This release marks an important point in API stability and going forward most API changes are expected to be additive in nature. This milestone opens the door for gRPC use in production environments. + +We’re also taking a big step forward in improving the installation process. Over the past few weeks we’ve rolled out gRPC packages to Debian Stable/Backports. Installation in most cases is now a two line install using the Debian package and available language specific package managers (maven, pip, gem, composer, pecl, npm, nuget, [pod](https://cocoapods.org/pods/gRPC)). In addition [gRPC docker images](https://hub.docker.com/r/grpc) are now available on Docker Hub. + + +We’ve updated the [documentation](/docs) on grpc.io to reflect the latest changes and released additional language-specific [reference docs](/docs/reference). See what’s changed with the Beta release in the release notes on GitHub for [Java](https://github.com/grpc/grpc-java/releases/tag/v0.9.0), [Go](https://godoc.org/google.golang.org/grpc), and [all other](https://github.com/grpc/grpc/releases/tag/release-0_11_0) languages. + +In keeping in line with our [principles](../principles) and goal to enable highly performant and scalable APIs and microservices on top of HTTP/2, in the coming months, the focus of the gRPC project will be to keep improving performance and stability and adding carefully chosen features for production use cases. Documentation will also be clarified and will continue to improve with new examples and guides. + + +We’ve been very excited to see the community response to gRPC and the various projects starting to use it ([etcd v3 experimental API](https://coreos.com/blog/etcd-2.2), [grpc-gateway](https://github.com/gengo/grpc-gateway) for RESTful APIs and others). + +We really want to thank everyone who contributed code, gave presentations, adopted the technology and engaged in the community. With your help support we look forward to the 1.0! diff --git a/content/blog/2016-5-9-coreos.md b/content/blog/coreos.md similarity index 98% rename from content/blog/2016-5-9-coreos.md rename to content/blog/coreos.md index 01ae868..544ba83 100644 --- a/content/blog/2016-5-9-coreos.md +++ b/content/blog/coreos.md @@ -1,14 +1,12 @@ --- attribution: Originally written by Brandon Phillips with additional content by Lisa - Carey and others at Google. + Carey and others at Google author: Brandon Phillips company: CoreOS company-link: https://coreos.com -date: "2016-05-09T00:00:00Z" -published: true +date: "2016-05-09" thumbnail: https://avatars2.githubusercontent.com/u/3730757?v=3&s=200 title: gRPC with REST and Open APIs -url: blog/coreos --- Our guest post today comes from Brandon Phillips of [CoreOS](https://coreos.com/). CoreOS builds open source projects and products for Linux Containers. Their flagship product for consensus and discovery [etcd](https://coreos.com/etcd/) and their container engine [rkt](https://coreos.com/rkt/) are early adopters of gRPC. diff --git a/content/blog/2018-12-18-grpc-dotnet-build.md b/content/blog/grpc-dotnet-build.md similarity index 99% rename from content/blog/2018-12-18-grpc-dotnet-build.md rename to content/blog/grpc-dotnet-build.md index 5012b3f..6dca898 100644 --- a/content/blog/2018-12-18-grpc-dotnet-build.md +++ b/content/blog/grpc-dotnet-build.md @@ -1,10 +1,8 @@ --- +title: "gRPC Meets .NET SDK And Visual Studio: Automatic Codegen On Build" author: Kirill 'kkm' Katsnelson author-link: https://github.com/kkm000 -date: "2018-12-18T00:00:00Z" -published: true -title: "gRPC Meets .NET SDK And Visual Studio: Automatic Codegen On Build" -url: blog/grpc-dotnet-build +date: "2018-12-18" --- As part of Microsoft's move towards its cross-platform .NET offering, they have diff --git a/content/blog/2019-09-23-grpc-on-dotnetcore.md b/content/blog/grpc-on-dotnetcore.md similarity index 98% rename from content/blog/2019-09-23-grpc-on-dotnetcore.md rename to content/blog/grpc-on-dotnetcore.md index af9f4e5..dad9243 100644 --- a/content/blog/2019-09-23-grpc-on-dotnetcore.md +++ b/content/blog/grpc-on-dotnetcore.md @@ -1,10 +1,8 @@ --- +title: .NET Core ❤ gRPC author: Sourabh Shirhatti author-link: https://twitter.com/sshirhatti -date: "2019-09-23T00:00:00Z" -published: true -title: .NET Core ❤ gRPC -url: blog/grpc-on-dotnetcore +date: "2019-09-23" --- _This is a guest post by [Sourabh Shirhatti](https://twitter.com/sshirhatti), a Program Manager on the .NET team at Microsoft._ diff --git a/content/blog/2016-4-4-installation.md b/content/blog/installation.md similarity index 67% rename from content/blog/2016-4-4-installation.md rename to content/blog/installation.md index 4b34b3e..c47137d 100644 --- a/content/blog/2016-4-4-installation.md +++ b/content/blog/installation.md @@ -1,20 +1,19 @@ --- +title: gRPC - now with easy installation attribution: Originally written by Lisa Carey with help from others at Google. -date: "2016-04-04T00:00:00Z" -title: gRPC - now with easy installation. -url: blog/installation +date: "2016-04-04" --- Today we are happy to provide an update that significantly simplifies the getting started experience for gRPC. - * For most languages, **the gRPC runtime can now be installed in a single step via native package managers** such as `npm` for Node.js, `gem` for Ruby and `pip` for Python. Even though our Node, Ruby and Python runtimes are wrapped on gRPC's C core, users now don't need to explicitly pre-install the C core library as a package in most Linux distributions. We autofetch it for you :-). - - * **For Java, we have simplified the steps needed to add gRPC support to your build tools** by providing plugins for Maven and Gradle. These let you easily depend on the core runtime to deploy or ship generated libraries into production environments. - - * You can also use our Dockerfiles to use these updated packages - deploying microservices built on gRPC should now be a very simple experience. - +* For most languages, **the gRPC runtime can now be installed in a single step via native package managers** such as `npm` for Node.js, `gem` for Ruby and `pip` for Python. Even though our Node, Ruby and Python runtimes are wrapped on gRPC's C core, users now don't need to explicitly pre-install the C core library as a package in most Linux distributions. We autofetch it for you :-). + +* **For Java, we have simplified the steps needed to add gRPC support to your build tools** by providing plugins for Maven and Gradle. These let you easily depend on the core runtime to deploy or ship generated libraries into production environments. + +* You can also use our Dockerfiles to use these updated packages - deploying microservices built on gRPC should now be a very simple experience. + The installation story is not yet complete: we are now focused on improving your development experience by packaging our protocol buffer plugins in the same way as the gRPC runtime. This will simplify code generation and setting up your development environment. ### Want to try it? diff --git a/content/blog/meetup-kit.md b/content/blog/meetup-kit.md new file mode 100644 index 0000000..7c1bb40 --- /dev/null +++ b/content/blog/meetup-kit.md @@ -0,0 +1,11 @@ +--- +title: The gRPC Meetup Kit +date: "2017-09-14" +attribution: Mark Mandel, Sandeep Dinesh +--- + +If you have ever wanted to run an event around [gRPC](/), but didn't know where to start, or weren't sure what content is available - we have released the [gRPC Meetup Kit](https://github.com/grpc-ecosystem/meetup-kit)! + +The meetup kit includes a 15 minute presentation on the basic concepts of gRPC, with accompanying [slides](https://docs.google.com/presentation/d/1dgI09a-_4dwBMLyqfwchvS6iXtbcISQPLAXL6gSYOcc/edit?usp=sharing) and [video](https://www.youtube.com/watch?v=UVsIfSfS6I4) for either reference or playback, as well as a [45-minute codelab](https://codelabs.developers.google.com/codelabs/cloud-grpc/index.html) that takes you through the basics of gRPC in [Node.js](https://nodejs.org) and [Go](https://golang.org). At the end of the codelab participants will have a solid understanding of the fundamentals of gRPC. + +If you are thinking about running a gRPC event, make sure to contact us to receive [gRPC stickers](https://goo.gl/forms/C3TCtFdobz4ippty2) and/or organise [office hours over Hangouts with the gRPC team](https://goo.gl/forms/pvxNwWExr5ApbNst2)! diff --git a/content/blog/principles.md b/content/blog/principles.md new file mode 100644 index 0000000..bdb81dc --- /dev/null +++ b/content/blog/principles.md @@ -0,0 +1,77 @@ +--- +title: gRPC Motivation and Design Principles +date: "2015-09-08" +attribution: Originally written by Louis Ryan with help from others at Google +--- + +## Motivation + +Google has been using a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across our data centers for over a decade. Our internal systems have long embraced the microservice architecture gaining popularity today. Having a uniform, cross-platform RPC infrastructure has allowed for the rollout of fleet-wide improvements in efficiency, security, reliability and behavioral analysis critical to supporting the incredible growth seen in that period. + +Stubby has many great features - however, it's not based on any standard and is too tightly coupled to our internal infrastructure to be considered suitable for public release. With the advent of SPDY, HTTP/2, and QUIC, many of these same features have appeared in public standards, together with other features that Stubby does not provide. It became clear that it was time to rework Stubby to take advantage of this standardization, and to extend its applicability to mobile, IoT, and Cloud use-cases.

+ +## Principles & Requirements + +### Services not Objects, Messages not References + +Promote the microservices design philosophy of coarse-grained message exchange between systems while avoiding the [pitfalls of distributed objects](https://martinfowler.com/articles/distributed-objects-microservices.html) and the [fallacies of ignoring the network](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing). + +### Coverage & Simplicity + +The stack should be available on every popular development platform and easy for someone to build for their platform of choice. It should be viable on CPU and memory-limited devices. + +### Free & Open + +Make the fundamental features free for all to use. Release all artifacts as open-source efforts with licensing that should facilitate and not impede adoption. + +### Interoperability & Reach + +The wire protocol must be capable of surviving traversal over common internet infrastructure. + +### General Purpose & Performant + +The stack should be applicable to a broad class of use-cases while sacrificing little in performance when compared to a use-case specific stack. + +### Layered + +Key facets of the stack must be able to evolve independently. A revision to the wire-format should not disrupt application layer bindings. + +### Payload Agnostic + +Different services need to use different message types and encodings such as protocol buffers, JSON, XML, and Thrift; the protocol and implementations must allow for this. Similarly the need for payload compression varies by use-case and payload type: the protocol should allow for pluggable compression mechanisms. + +### Streaming + +Storage systems rely on streaming and flow-control to express large data-sets. Other services, like voice-to-text or stock-tickers, rely on streaming to represent temporally related message sequences. + +### Blocking & Non-Blocking + +Support both asynchronous and synchronous processing of the sequence of messages exchanged by a client and server. This is critical for scaling and handling streams on certain platforms. + +### Cancellation & Timeout + +Operations can be expensive and long-lived - cancellation allows servers to reclaim resources when clients are well-behaved. When a causal-chain of work is tracked, cancellation can cascade. A client may indicate a timeout for a call, which allows services to tune their behavior to the needs of the client. + +### Lameducking + +Servers must be allowed to gracefully shut-down by rejecting new requests while continuing to process in-flight ones. + +### Flow Control + +Computing power and network capacity are often unbalanced between client ands server. Flow control allows for better buffer management as well as providing protection from DOS by an overly active peer. + +### Pluggable + +A wire protocol is only part of a functioning API infrastructure. Large distributed systems need security, health-checking, load-balancing and failover, monitoring, tracing, logging, and so on. Implementations should provide extensions points to allow for plugging in these features and, where useful, default implementations. + +### Extensions as APIs + +Extensions that require collaboration among services should favor using APIs rather than protocol extensions where possible. Extensions of this type could include health-checking, service introspection, load monitoring, and load-balancing assignment. + +### Metadata Exchange + +Common cross-cutting concerns like authentication or tracing rely on the exchange of data that is not part of the declared interface of a service. Deployments rely on their ability to evolve these features at a different rate to the individual APIs exposed by services. + +### Standardized Status Codes + +Clients typically respond to errors returned by API calls in a limited number of ways. The status code namespace should be constrained to make these error handling decisions clearer. If richer domain-specific status is needed the metadata exchange mechanism can be used to provide that. diff --git a/content/blog/2016-3-24-pubsub.md b/content/blog/pubsub.md similarity index 100% rename from content/blog/2016-3-24-pubsub.md rename to content/blog/pubsub.md diff --git a/content/blog/2016-07-25-vendasta.md b/content/blog/vendasta.md similarity index 99% rename from content/blog/2016-07-25-vendasta.md rename to content/blog/vendasta.md index 63a338f..2160160 100644 --- a/content/blog/2016-07-25-vendasta.md +++ b/content/blog/vendasta.md @@ -1,14 +1,13 @@ --- +title: Why we have decided to move our APIs to gRPC attribution: Originally written by Dale Hopkins with additional content by Lisa Carey and others at Google. author: Dale Hopkins company: Vendasta company-link: https://vendasta.com -date: "2016-07-25T00:00:00Z" +date: "2016-07-25" published: false thumbnail: ../img/vend-icon.png?raw=true -title: Why we have decided to move our APIs to gRPC -url: blog/vendasta --- Our guest post today comes from Dale Hopkins, CTO of [Vendasta](https://vendasta.com/). Vendasta started out 8 years ago as a point solution provider of products for small business. From the beginning we partnered with media companies and agencies who have armies of salespeople and existing relationships with those businesses to sell our software. It is estimated that over 30 million small businesses exist in the United States alone, so scalability of our SaaS solution was considered one of our top concerns from the beginning and it was the reason we started with Google App Engine (Python GAE) and Datastore. This solution worked really well for us as our system scaled from hundreds to hundreds of thousands of end users. We also scaled our offering from a point solution to an entire platform with multiple products and the tools for partners to manage their sales of those products during this time. diff --git a/layouts/partials/blog/hero.html b/layouts/partials/blog/hero.html index c701336..ba7703b 100644 --- a/layouts/partials/blog/hero.html +++ b/layouts/partials/blog/hero.html @@ -5,7 +5,7 @@
-

+

{{ $title }}

@@ -15,6 +15,12 @@

{{ end }} + {{ with $desc }} +

+ {{ . }} +

+ {{ end }} +

{{ $date }}