Please note: Mirantis has realigned its portfolio and renamed several products. These include Docker Enterprise Container Cloud (now Mirantis Container Cloud), Docker Enterprise/UCP (now Mirantis Kubernetes Engine), Docker Engine - Enterprise (now Mirantis Container Runtime), and Docker Trusted Registry (now Mirantis Secure Registry).

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

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

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.