How HyScale’s App-Centric Abstraction solve Kubernetes complexities?
July 9, 2020 - by Jayalakshmi Elango
Most enterprises aspire to move to Kubernetes abstraction to avail the intended benefits of containers – cost, portability, scalability, and more. But, in reality, migration brings with it several complexities. In our experience, to ensure smooth deployment of apps to K8s, we’ve seen application teams need two things – Abstraction & Automation.
As your enterprise application grows in complexity and as you scale out your K8s adoption to more apps, you start to stare at a long, tedious process of migrating these apps, troubleshooting errors and maintaining large amounts of K8s manifest yamls. These necessitate an automation platform that provides an App-centric Abstraction experience to overcome the complexities of K8s., during any application run for specific tasks like troubleshooting, CI/CD, tracking, monitoring, multi-cloud visibility, etc.
Uncomplicating Kubernetes with HyScale’s App-centric Abstraction
Before looking into the details of HyScale, let’s first understand the basics of abstraction and
why we need it.
What is Abstraction ?
Abstraction is a simplified version of a technical program or function that reduces its complexity by removing unnecessary information.
Let’s look at a simple analogy of jQuery and Javascript to understand Kubernetes abstraction better. In the code below, you can see the Javascript version is far more verbose and involves several lower level objects such as alpha, opacity, etc. Hence, jQuery was built on top of Javascript to simplify the development process.
Like jQuery is to Javascript; similarly, “HyScale’s App-centric” abstraction layer is to Kubernetes.
jQuery : JavaScript : : Abstraction : Kubernetes
jQuery
$(document).ready(function() {
$(#clickedElement).clickfunction(){
$(#fadedElement).fadeOut();
});
});
javascript
function fadeThisElement(elm) {
for (var i=10; i>0; i--) {
var opacity = i/10;
setTimeout( function(opacity) {
elm.setStyle(“-moz-opacity”, opacity);
elm.setStyle(“opacity”, opacity);
elm.setStyle(“filter”, “alpha(opacity=“ + (opacity*100).toString() );
}, 100;
}
}
window.onload = function() {
document.getElementsById(“clickedElement”).onclick = function() {
fadeThisElement(document.getElementById(‘fadedElement’));
}
}
Similarly, HyScale’s App-centric approach involves a simplified HyScale Spec file ( hSpec ), that helps app teams deploy to Kubernetes easily and effortlessly.
Some of the examples of hSpec file are,
App-centric Abstraction (“hspec”)
-name: tomcat-logs path:/usr/local/tomcat/logs
Size: 1Gi
overrides: my-service
replicas:
min: 1
max: 4
cpuThreshold: 30%
JAVA_HOME: /usr/local/java
TOMCAT_HOME: /usr/local/tomcat
secrets:
- MYSQL_PASSWORD
- port: 8080/tcp
healthCheck:
httpPath: /docs/images/tomcat.gif
Key advantages of abstraction in software:
- Simple and easy to understand
- Fewer lines of code
- Less complicated and easy to maintain
- Fewer mistakes and faster to learn
App-centric Abstraction
In the Kubernetes world, there’s a whole lot of underlying complexity. Your services/applications may not need all of these things, but it is essential to know which of these you should know and how they fit together.
We have worked over the last two years to create an Kubernetes abstraction through App-centric approach. So that developers or application teams can simply specify the deployment needs of their service declaratively in a terminology that they already understand and would not have to deal with a whole lot of low level objects. A DevOps person, for instance, can easily understand these high-level objects and deploy them with minimal effort.
Here are some of the high-level objects specified by the abstraction :
App | Profile | ConfigProps | Agents |
Service | Volumes | Secrets | Jobs |
Dependency | HealthChecks | Memory/CPU | LoadBalancer |
Environment | Ports | Replica | Initialization/Finalization |
Kubernetes Complexity (A glimpse)
pods | hostAlias | accessModes | targetPort |
statefulSet | hostname | dataSource | sessionAffinity |
replicaSet | imagePullSecrets | storageClassName | healthCheckNodePort |
deployments | initContainers | CronJob | Ingress |
daemonSet | nodeSelector | concurrencyPolicy | IngressController |
sidecar | restartPolicy | failedJobsHistoryLimit | annotations |
configMap | preemptionPolicy | successfulJobsHistoryLimit | labels |
imagePullPolicy | serviceAccount | Schedule | endpoints |
lifecycleHooks | tolerations | Suspend | endpointSlices |
livenessProbe | terminationGracePeriod | jobTemplate | targetRef |
readinessProbe | replicas | backoffLimit | topology |
startupProbe | revisionHistoryLimit | Completions | persistentVolumeClaim |
resources | minReadySeconds | Parallelism | horizontalPodAutoscaler |
resourceTypes | progressDeadlineSeconds | clusterIP | metricSpec |
limits | selector | loadBalancerIP | scaleTargetRef |
securityContext | rollingUpdate | externalIPs | networkPolicy |
capabilities | podManagementPolicy | externalName | egress |
volumeMounts | updateStrategy | externalTrafficPolicy | ingress |
affinity | volumeClaimTemplates | loadBalancerSourceRanges | podSelector |
dnsConfig | volumeMode | nodePort | policyTypes |
Why do we need App-centricity in the first place?
- This App-centric Abstraction is created intentionally at a high-level language without getting into the granular details of Kubernetes terminologies.
- The primary goal of creating such App-centric concepts is to provide self-service to deliver/deploy your application quickly into Kubernetes Abstraction with multiple clouds.
- Easily understandable and easy to maintain by app teams, who need not spend time learning the complex Kubernetes language.
- It helps you auto-generate and maintain all the YAML files and docker files required
Features of HyScales’s App-centric Abstraction:
HyScale’s App-centric Astraction helps you achieve the following with just a few lines of declaration:
- Setting up resource-limits and enabling auto-scaling.
- Enabling health-checks on an HTTP path or TCP port.
- Declaring volume paths for storing service data.
- All the configuration property details are automatically available as a file within the running pod and as env props in the service containers.
- Declaring the keys for secrets such as passwords & tokens available automatically from the K8s secrets store.
- Attaching log, monitoring, and tracing agents to the service.
- Override or add different configurations for different environments using profiles.
How did HyScale abstract K8S
Let us take an example; suppose the service needs to create a data pod to store the data,
- The tool will infer that it needs to generate a stateful of YAMLs, PVC template, and so on.
- Translate the app requirements into the K8s YAMLs, which translates all into the relevant kinds and resources.
- Bind them together with different Kubernetes objects YAMLs with the right labels for easy debugging and troubleshooting in a more simplified manner.
Examples of HyScale’s hSpec File
Feature: Autoscaling
It helps application deployment teams scale infrastructure for dynamic loading, as infrastructure is directly proportional to application traffic. But DevOps teams cannot manually monitor their traffic to increase the load. So the need for autoscaling in DevOps teams became significant.
Autoscaling:
Click here for autoscaling sample
Feature: Profiles
Managing configurations files for multiple environments(like dev, QA, stage, prod) is very much necessary for application deployments. On the same page, it must deploy the same application code in all environments in the CI/CD pipeline.
hprof is a convention/spec we use at Hyscale to store the difference of configuration. Hyscale ensures that users override only essential properties in environments with hprof. So deployments are meaningful when hspec combined when using with relevant profiles.
Profiles:
Want to know more about profile file? Click here
Feature: Agents
Application containers should always address a single responsibility. Other aspects of service can be decoupled and addressed as a sidecar pattern in the container world. Sidecars are containers that help primary containers to perform their work. Examples for any sidecar containers are logging agents (fluentd, logstash, etc.), monitoring agents, proxy agents, etc.
Agents:
Here’s an example for agent hspec
Workflow behind the Abstraction
When a developer invokes a hspec file, internally HyScale performs a series of steps. It generates docker files, builds docker images and auto-generates the K8s manifests files and deploys them to the Kubernetes Cluster. At the end of the command process, you get a URL with which to access your application! Here’s an example of a hSpec file
Here’s a glimpse of what HyScale does when you invoke it,
With HyScale’s App-centric or Application-centric approach, app teams can skip the tedious repetitive tasks, and embrace the benefits of Kubernetes quickly, without battling its complexities. This cloud native deployment platform provides a standard way of doing things so that the multiple apps & services can be deployed rapidly to K8s in a standard way without reinventing the wheel.
After all, the goal is to build fast and deploy even faster, and use precious developer time to ship out powerful applications. That’s what HyScale’s App-centric Abstraction is all about.
Save 90% of your
Environment set-up time
Cut down repetitive
tasks by 6X
Achieve faster
feedback Loop
Experience App Centric
Abstraction