Januar 2021 - Seite 16 von 40 - Cloud Computing Köln

We are excited to announce a broad set of new traffic serving capabilities for Cloud Run: end-to-end HTTP/2 connections, WebSockets support, and gRPC bidirectional streaming, completing the types of RPCs that are offered by gRPC. With these capabilities, you can deploy new kinds of applications to Cloud Run that were not previously supported, while taking advantage of serverless infrastructure. These features are now available in public preview for all Cloud Run locations.Support for streaming is an important part of building responsive, high-performance applications. The initial release of Cloud Run did not support streaming, as it buffered both the request from the client and the service’s response. In October, we announced server-side streaming support, which lets you stream data from your serverless container to your clients. This allowed us to lift the prior response limit of 32 MB and support server-side streaming for gRPC. However, this still did not allow you to run WebSockets and gRPC with either client-streaming or bidirectional streaming.WebSockets and gRPC bidirectional streamingWith the new bidirectional streaming capabilities, Cloud Run can now run applications that use WebSockets (e.g., social feeds, collaborative editing, multiplayer games) as well as the full range of gRPC bi-directional streaming APIs. With these bidirectional streaming capabilities, both the server and the client keep exchanging data over the same request. WebSockets and bidirectional RPCs allow you to build more responsive applications and APIs. This means you can now build a chat app on top of Cloud Run using a protocol like WebSockets, or design streaming APIs using gRPC.Here’s an example of a collaborative live “whiteboard” application running as a container on Cloud Run, serving two separate WebSocket sessions on different browser windows. Note the real time updates to the canvases on both windows:Using WebSockets on Cloud Run doesn’t require any extra configuration and works out of the box. To use client-side streaming or bidirectional streaming with gRPC, you need to enable HTTP/2 support, which we talk about in the next section.To try out a sample WebSockets application on Cloud Run, deploy this whiteboard example from Socket.io by clicking on this link.It’s worth noting that WebSockets streams are still subject to the request timeouts configured on your Cloud Run service. If you plan to use WebSockets, make sure to set your request timeout accordingly.End-to-end HTTP/2 supportEven though many apps don’t support it, Cloud Run has supported HTTP/2 since its first release, including end-to-end HTTP/2 for gRPC. It does so by automatically upgrading clients to use the protocol, making your services faster and more efficient. However, until now, HTTP/2 requests were downgraded to HTTP/1 when they were sent to a container.Starting today, you can use end-to-end HTTP/2 transport on Cloud Run. This is useful for applications that already support HTTP/2. For apps that don’t support HTTP/2, Cloud Run will simply continue to handle HTTP/2 traffic up until it arrives at your container.For your service to serve traffic with end-to-end HTTP/2, your application needs to be able to handle requests with the HTTP/2 cleartext (also known as “h2c”) format. We have developed a sample h2c server application in Go for you to try out the “h2c” protocol. You can build and deploy this app to Cloud Run by cloning the linked repository and running:In the example command above, the “–use-http2″ option indicates that the application supports the “h2c” protocol and ensures the service gets the HTTP/2 requests without downgrading them.Once you’ve deployed the service, use the following command to validate that the request is served using HTTP/2 and not being downgraded to HTTP/1:curl -v –http2-prior-knowledge https://<SERVICE_URL>You can also configure your service to use HTTP/2 in the Google Cloud Console:Getting started With these new networking capabilities, you can now deploy and run a broader variety of web services and APIs to Cloud Run. To learn more about these new capabilities, now in preview, check out the WebSockets demo app or the sample h2c server app.If you encounter issues or have suggestions, please let us know. You can also help us shape the future of Cloud Run by participating in our research studies.Related ArticleIntroducing HTTP/gRPC server streaming for Cloud RunYou can now stream large or partial responses from Cloud Run to clients, improving the performance of your applications.Read Article
Quelle: Google Cloud Platform

21. Januar 2021

da Agency

Kubernetes Training Webinar Q&A: Running with the Application Essentials

The post Kubernetes Training Webinar Q&A: Running with the Application Essentials appeared first on Mirantis | Ship Code Faster.
Last week we teamed up with our training partner ExitCertified to present our most successful webinar ever, “Running with the Application Essentials,” which attracted nearly 3,000 registrants! Here we’ve taken the time to answer all the questions we received from the audience, but we’d love for you to view the whole webinar!
Are there any macro services?
Compared to the term “microservices”, the terminology commonly used as a point of comparison is “monolithic application.”
How would a microservice application coalesce information? Is there another layer to this?
Great question. The short answer is to start looking at the API composition pattern. You will need an API composer than can handle sending queries to the backend services and then performing an in-memory join of the results (for example).
One advantage you forgot to mention is that you have the ability to do a blue-green deployment during business hours while the system is live, saving time and costs.
I hinted at it. But yes blue-green deployments, canary testing, A/B testing, and so forth are great to include in the software lifecycle and can make up for any deficiencies in the rounds of pre-production testing of code changes in cloud-native applications, while at the same time mitigating against downtime with each code release.
Can I think of microservices as decomposing all of the subprocedures and functions in my ASP page into their own microservices?
In a manner of speaking, yes. Conceptually, that is one way of thinking about functional decomposition.
Are there at least two levels of testing with microservices? First, is there more of a unit test that tests all of the possible inputs/outputs expected? And then is there a system test that takes into account multiple miroservices that together perform some business action?
Testing code changes of an application decomposed into microservices is a complex topic that requires specific attention to the strategy for testing. While unit and integration testing are quite a common approach for testing code fixes or minor enhancements for microservices, other testing approaches include a controlled rollout into production (for example, canary testing, A/B testing, and so forth) for code changes where pre-production testing would be considered too costly in terms of time to develop and deliver. The more complex the application, the increased difficulty of testing. A controlled rollout of a code change should allow for a quick rollback if an unintended error is introduced.
Should a development approach be to prototype my concept with the monolithic approach, then thereafter build the final product as a microservice architecture?
That really depends on time to deliver final product and value gained by prototyping monolithic only to deliver in microservices. Both architectures have their benefits and drawbacks. If the the application is small enough to be developed and maintained in a monolithic architecture pattern, then the recommendation is to proceed accordingly. However, when scoping the requirements of the application suggests a level of complexity that will require multiple teams of developers and requires rapid release cycles (continuous delivery / deployment), then microservices seems like the right choice.
On top of the testing question, what is the difference between microservice and monolithic in terms of testing, if unit and system tests are the same. I still would need to do unit tests and a system test in monolithic development.
Testing in a distributed system, as I have described, is quite complex comparatively. As in a monolith, testing is straightforward: either the application features are all available or the application is not available at all. In an application developed in a microservice pattern, software testing methods need to be carefully considered in the design phase of the application. For example, unit and integration testing code changes are specific to the target service, not all services comprising the application. Depending upon the application and business requirements, other types of pre-produciton and production testing may also be considered, such as blue-green deployments, canary testing, and so on.
You mentioned but did not define, Kubelet, Kubelet-Proxy, Master/Worker nodes and Pod
Yes my main point is to provide an introduction to the Kubernetes architecture, and highlight which components (such as kubelet and kube-proxy) provide resiliency with respect to running applications within the cluster. In the complete Mirantis training course, CN 120: Kubernetes Application Essentials, we provide a thorough presentation on the main components that make up the architecture of the Kubernetes platform.
How is state integrity ensured for stateful applications such as databases (MS SQL, My SQL, Maria DB, and so on) running on multi-node Kubernetes?
Good question! To add to the point of Persistent Volumes and PVCs, the Kubernetes object to consider is the StatefulSet object with the corresponding headless Service object. In your specific example of a database, additional configuration is required to ensure High Availability (HA) across multiple pods within the StatefulSet. The Kubernetes documentation provides a tutorial on configuring HA for MySQL as found here (https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/). While not the only approach, the tutorial should provide you with a good start in such a case. To further add as a point of consideration, the main drivers of using Kubernetes is a cloud-native technology stack specifically meaning datastores that are cloud-native. You may want to consider other cloud-native datastores as a comparison, such as CockroachDB.
How are these pods secured by encryption?
Pods do not offer any kind of native encryption of the data they handle. With some exceptions for Kubernetes components, encrypting application network traffic and data at rest within the cluster is not handled natively. Additional addons and environment configuration are necessary to achieve encryption in both cases.
Does Mirantis run its own datacenters for the Mirantis Cloud Native Platform or 3rd party provider datacenters (AWS, Google, Azure, etc.)?
Mirantis Cloud Native Platform runs on customers’ public or private clouds or on bare metal.
Is there a community edition of Mirantis Kubernetes Engine for self learning?
A trial version is available. If you are interested in downloading and practicing on the Mirantis Kubernetes Engine (MKE) you can do so easily with Mirantis Launchpad. See more information directly on our website: https://www.mirantis.com/software/docker/download/.
Should you have Ops Before Dev? Or can you just jump into Dev Track with developer experience but very little Kubernetes and little to moderate Docker?
In terms of the Mirantis learning track, we recommend the Container Essentials -> Kubernetes Application Essentials -> Kubernetes Native Application Development. Although an option, the Operations course is geared towards Kubernetes operations management.
Is the COA exam is still available?
Yes it is! To get started, have a look here: https://www.openstack.org/coa/. Additionally if you are ready to register, you can take a look at all of the available sessions here: https://coa.arlo.co/w/events/1-coa-certified-openstack-administrator
I’d like some articles about K8s security. Thanks!!
A site that has a great list of articles organized by Kubernetes Security topics can be found here: https://kubernetes-security.info/
Can you please elaborate on service discovery?
Kubernetes provides two primary modes of finding a service within a cluster: environment variables and DNS. If a service exists at time of pod creation, then that service will be made available to the containers within the pod as environment variables. The DNS option allows for applications to contact services by DNS name, assuming the cluster is configured with a DNS service (highly recommended).
Thanks for joining us, and again, check out the full webinar!
Interested in taking a class from Mirantis Training? Check out our course catalog and public class schedule.
The post Kubernetes Training Webinar Q&A: Running with the Application Essentials appeared first on Mirantis | Ship Code Faster.
Quelle: Mirantis