Infrastructure Is Relevant to Developers
As we enter 2018, the lines between infrastructure and software continue to blur. In some ways software is getting further and further away from the underlying hardware that makes it work. We have seen this with the introduction of IaaS, then PaaS, and now Functions as a Service (aka Serverless). Yet, you can’t run software out of thin air (yet), and the general trend towards software skills being part of an infrastructure developers toolkit provide us with an opportunity. The so-called DevOps trend has many benefits, but one that I’ve been thinking about is how the expertise of Dev and Ops can help each side create better outcomes.
In many ways, the lingua franca of DevOps is APIs. The ability to automate from the lowest level to the highest level in a solution is incredible. We’re building systems these days — not just siloed implementations of a network, a server, an app, a database, and so on. As a result, my system should try to take advantage of information that it can glean from the infrastructure on which it is running. One thing that you may be thinking is, “OK great, we monitor our systems, isn’t that enough?” It’s not enough if you want to also be able to debug the problems that may have caused the issues in the first place. So, now we have a new term known as “observability,” which desires to create systems that include rich context that are great for debugging. If you want to read more about this, I highly recommend this post from Cindy Sridharan.
Building a Simple Healthcheck for an App
With all of this in mind, I wanted to see if I could build a simple healthcheck style scenario for an app. In the end, combining data from the network controller as part of my app infrastructure provides new context to my debugging and troubleshooting, but also helps break down the divide between the network and higher level parts of the system.
I chose SpringBoot for this experiment, largely because it is becoming more popular for rapid development in the Java world, and it includes a built-in health checking module as part of the Spring Boot Starter Actuator package.
With an eye on re-usability, I created a Java library that I called “libinfracheck”. In this library, which gets invoked by the main application health check endpoint, a REST API call will be sent to the Cisco APIC-EM path trace API (/v1/flow-analysis). It uses a pre-determined pathId. In the future, you will also be able to do similar things using Cisco DNA Center APIs. In a real scenario, you would probably need to define this dynamically. What gets returned is the result of that path trace.
// InfraCheck.java
String BASE_URL = "https://sandboxapic.cisco.com/api";
String APICEM_AUTH = BASE_URL.concat("/v1/ticket");
String APICEM_PATHTRACE = BASE_URL.concat("/v1/flow-analysis");
//snip
HttpResponse
.header("X-Auth-Token", apicemTicket)
.asJson();
// code continues
In the application health check, you translate the results into a meaningful error condition.
// InfraCheckHealthIndicator.java
…
if (healthStatus.equals(“FAILED”)) {
Result result;
try {
result = mapper.readValue(response.getBody().getObject().toString(), Result.class);
} catch (IOException e) {
throw new RuntimeException(“ERROR”);
}
return Health.down().withDetail(“Error Code”, result).build();
}
return Health.up().build();
…
With this fairly simple example, you can see how the infrastructure is now providing your application with more context in order for you or the system itself to respond to outage type scenarios.
You can get the code from GitHub:
To see this in action, I invite you to join me at Cisco Live 2018 in Barcelona for my session “Use the infrastructure, Luke!” — DEVNET-1047.
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Twitter @CiscoDevNet | Facebook | LinkedIn
Visit the new Developer Video Channel
CONNECT WITH US