#dev-ops

Don’t snapshot your UI components, make assertions!

Great post discussing unit test and the reason behind making assertions vs snapshot UI. More of philosophical that hopefully shape how you think about unit testing. Good read.

Something to Know about gRPC in ASP.NET Core 3

gRPC is on the rise! And so is ASP.NET Core 3! But wait, it’s not working in Azure App Service? Head on to …

How to identify web app changes to triage and root cause live site issues

I think every developer has spent countless time troubleshooting what goes wrong with their production system. “It was working fine yesterday!”. With Azure App Services, you can now identify changes that happen in your web app. Checkout the Azure Friday video!

Why Continuous Deployment matters to business

M…

Quickstart: Deploy Linux containers to Service Fabric

Azure Kubernetes Service is really cool to deploy your container to. However, what most people don’t know is, you can deploy the same container to Service Fabric. The benefit? You don’t have VMs to manage in Service Fabric.

Optimize the performance of Azure Cosmos DB by using partitioning and indexing strategies

If you’re usin…

Dev-ops are cool ! So you wanne be cool. Learn the following nice features with Open NX-OS for the Nexus 9000:

What can you do when you login with a dev-ops role on a Nexus 9000:

N9K-OpenNXOS# sh role name dev-ops

Role: dev-ops

  Description: Predefined system role for devops access. This role

  cannot be modified.

  ——————————————————————-

  Rule    Perm    Type        Scope               Entity                  

  ——————————————————————-

  6       permit  command                         conf t ; username *     

  5       permit  command                         attach module *         

  4       permit  command                         slot *                  

  3       permit  command                         bcm module *            

  2       permit  command                         run bash *              

  1       permit  command                         python * 

Lets enable the bash-shell and nxapi feature :

N9K-OpenNXOS# conf t

You don't have to go far to find people claiming that one of Ansible's strengths is its "declarative" configuration. Some claim this declarative language is better than, say Ruby (used in Chef) or Puppet's custom language. Now, this may indeed be true, but let's get into the details. What declarative language does Ansible use? YAML. This does not seem to raise eyebrows.

My goal is simple. Next time you see any person or project using YAML as a declarative programming language, I want you to raise an eyebrow. If you do this, then I will be happy.

Let's have some fun. What would people say if Ansible had chosen a different "declarative" language? Pick your favorite. Go on.

Oh, you picked XML? Me too! Let's think about it: what would happen if Ansible went with XML instead of YAML?

Madness. Chaos. People would run Ansible straight out of town! The pain from XML is still too fresh.

This is strange, though, because YAML isn't fundamentally different. Yes, I realize that YAML is easier on the eyes (and soul) than XML, but both are fundamentally languages for data transport, not programming.

Perhaps Rails made YAML hip. Perhaps others have not yet despoiled YAML. I suggest to you that Ansible may have, under your very noses, taken YAML too far. Let me explain.

But back to our thought experiment: Ansible + XML! There is little love lost on XML. Big surprise. In addition to being an unwieldy data format for humans to write without significant tool support, it also has come to embody the idea of configuration-gone-too-far. In order to use XML for logic, one often re-invents ways of handling variables, control flow, iteration, and more. To do so, one must create a programming language. Alas, it may not be a good one.

Here is my point: if you find yourself creating a new programming language, why use data exchange format as the substrate? I have a few guesses.

Guess #1: Perhaps you don't realize that you are creating a programming language. You just went for it.

Guess #2: You thought about using an existing language, such as Ruby or Python, but were concerned about users abusing the power.

Guess #3: You didn't want to have to write a parser for a custom language. You chose a data language (e.g. XML or YAML) because it is syntactically easy to parse.

To comment on the last theory: parsing the syntax is the easy part. Afterwards, you have to build additional logic (that acts effectively as a run-time) that can execute your programs. Maybe this is easy too, at least at the beginning.

Perhaps, to start, you only need a few language features; perhaps only some basic looping. But then what about sorting, conditionals, custom functions, and so on? As your tool becomes more popular, I predict you'll find that your users, which happen to be software developers, will ask for more programming-language capabilities.

Personally, I felt a bit uneasy when I saw Ansible using YAML. This uneasiness became more pronounced when I saw `with_items`. Some might say that `with_items` is a helpful hack given the YAML constraints. That's my whole point: Ansible has invented a programming language (a DSL within YAML), probably without admitting it.

My tentative view is that Ansible is taking an Icarus-inspired risk in using data-exchange language for configuration management. My hunch is that an existing programming language would be better suited.

Thankfully Ansible is not using XML, but that don't let that comfort you. YAML isn't fundamentally better, since it is still a data-interchange format.

I see YAML-as-configuration-management as a problem because there have to be better options. Hundreds, if not thousands, of programming languages have evolved to address abstraction, composability, and readability in various ways. It seems like a shame to fall back on YAML without a very good reason.

Yes, this is a one-sided argument. Otherwise, Ansible seems to be a nice configuration management (and remote execution) tool. As a practical matter, YAML may have been a reasonable place to start.

And please don't tell me YAML is a nice choice simply because it is declarative. It is a declarative data language, not a declarative programming language. There are declarative languages that solve particular problems very well. Some of my favorites are: Prolog, SQL, and Verilog. (I realize that if you made it this far into this rant, I might as well compliment SQL while I had the chance.)

That's all I've got for now. If you have ideas for building an elegant declarative language for configuration management, please get in touch.

P.S. I'm not particularly satisfied with the configuration management tools I've seen. They seem too complicated from a data modeling point of view. There seem to be too many arbitrary names being created. It seems to me that all we need are basic functions that can be called, composed, serialized, and versioned. I certainly don't have it figured out, but I have the impression that no one else has really nailed it either.

Who we are:

Topspin is a direct-to-fan sales and marketing platform used by Paul McCartney, Eminem, Beastie Boys, Jay-Z & Kanye West, Kevin Smith, Trent Reznor and Arcade Fire. Topspin helps thousands of musicians, filmmakers and other artists grow their audience and sell their work. Topspin's software distributes your fan engagement and commerce widgets into channels where your fans are actively consuming and sharing your media including YouTube, MTV, Facebook, Twitter,  and across the web.

Why you want to work here:

Highly visible (We work with a large number of artists including the biggest names in the industry.  We also power highly trafficked sites such as artists.mtv.com)

Small engineering team with large impact

Collaborative environment (both within engineering as well as throughout the company)

Company culture (in office performances, table-tennis, regular outings to industry events and shows)

What we need:

Dev-ops engineering to upgrade and scale our AWS infrastructure

Detail obsessed

Highly communicative

Comfortable writing code (we use Chef) as well as traditional ops tasks (such as verifying a database restore)

Are we cool? Yes.