Thursday, October 08, 2015

Containers: Don't Skeu Them Up (LinuxCon Europe 2015)

Skeuomorphism usually means retaining existing design cues in something new that doesn't actually need them. But the basic idea is far broader. For example, containers aren't legacy virtualization with a new spin. They're part and parcel of a new platform for cloud apps including containerized operating systems like Project Atomic, container packaging systems like Docker, container orchestration like Kubernetes and Mesos, DevOps continuous integration and deployment practices, microservices architectures, "cattle" workloads, software-defined everything, management across hybrid infrastructures, and pervasive open source.

This session discusses how containers can be most effectively deployed together with these new technologies and approaches -- including the resource management of large clusters with diverse workloads -- rather than mimicking legacy sever virtualization workflows and architectures.

This version of the presentation is significantly reworked from earlier. It excises much of the container background while adding discussion on microservices alternatives and services orchestration.

Links for 10-08-2015

Tuesday, September 29, 2015

Podcast: Making DevOps succeed with Red Hat's Jen Krieger


Red Hat Agile Coach Jen Krieger has extensive experience working with development teams on a wide range of projects. Currently, she’s focused on Project Atomic.  his experience has given her great insights into what makes teams and projects work and what roadblocks get in the way. In this podcast, Jen shares those insights as well as specific steps that you can take to make your DevOps initiatives successful.

Listen to MP3 (17:21)

Listen to OGG (17:21)


Gordon Haff:  Hi, everyone. This is Gordon Haff at Red Hat with another edition of the "Cloudy Chat" podcast. We're going to go back to DevOps today. I'm speaking with Jen Krieger, who is an agile coach at Red Hat.

Our topic for today is, "What are the inhibitors to getting DevOps done right at your organization, at multiple levels within the organization?" Jen, welcome. What is the first thing that comes to mind that gets in the way of successful DevOps?

Jen Krieger:  If you go online, and you type in "Cultural blockers to DevOps" in the Google and look at that search, you'll probably see the majority of the answers are going to be somewhere in the realm of two words, the first one being "trust," and the second one being "empathy."

What I rarely see, or maybe I do, but perhaps not necessarily directed at an individual, or an executive is, what things people can do to change those things. As in, "How can I be more trustworthy of my co‑workers," or "How can I have more empathy?"

It's easy to just tell somebody to more empathetic, but maybe not so easy in individual situations, or maybe it's hard to remember those things.

One of the things I'd like to tell people in general, especially the individual contributors is, when we're talking about trust and empathy a lot of times, it's hard to get to that place. As in, you have a collaborator sitting next to you, and they're doing something that is making you unhappy, or they've done something that has blown up your work week, because they did something wrong.

It's hard for you to have that empathy, especially if there is a sense of competition in the workplace. I've been at many companies now. A large portion of them, there's always seems to be a limited number of jobs, limited number of promotions, limited number of salary increases. I've heard, "Well, we only have X number of percent for salary increases or bonuses this quarter, and you got more than so and so."

The conversation always seems to breed competition, making it less likely that I want to cooperate with somebody, because I want that additional money. What I think employers don't understand is, when they are putting their employees in that situation.

They're starting to allow for this situation occur, where the co‑worker or the individual was not only competing with the people around them, but they're also starting to compare the company that they're working with to other companies, even competitors.

You're not only breeding competition internally, but you're also breeding competition with the people outside of your workplace.

This is not an easy problem to solve. No one has unlimited money to do whatever they want with it. No one has an unlimited number of promotions.

There's not always spaces for everybody in management, or wherever they want to take their career. There are some things that we can do as an organization that alleviate some of those situations, to help everyone.

At the executive level, what I like to tell people is, "We need to start looking at the tech industry." There is an alarming trend sometimes, where we hire and promote technical people into management positions, because they're really great technologists.

Maybe not so great at being the kind of person, who is interested in mentoring an employee, or interested in employee development.

A lot of companies will do this thing, where they have almost like a one‑size‑fits‑all employment development plans. If you are somebody who likes a lot of hands‑on interaction is probably a good situation for you, because you'll have those touch points with your manager, and they're pretty structured.

If you're somebody who is more introverted or not interested in having that conversation, then it can be overwhelming for you to have that constant touch point with your manager. Having somebody who doesn't really understand employees and individual and needs an individual‑employee development plan or individualized attention is going to be hard.

Especially if that person is more interested in the technology side of things, versus the human interaction and development side of their job.

I also like to tell them that encouraging spot awards or some sort of system, where individuals can award individuals, or individuals can award executives or vice versa, where you just have a pool of money or a pool of points or some way to say, "Hey, thank you so much for what you did, " and to use that as a way to recognize people.

You can be an individual contributor, instead of having a verbal conversation saying, "Thank you for what you did," something that doesn't get tracked, something that your boss doesn't know about, or something that when the next promotion comes up, no one knows about.

Having those automated spot awards or some sort of system that's tracked for that, cannot only help teams feel little more cooperative with one another as in, "Hey, we're all working together to get something done."

Also, help management find introverts in their organization, who may not be speaking up and may not be saying, "Hey, look at what I did over here," they may be always had astound doing a fantastic job. Therefore, no one notices what it is they're doing for the organization. I would also encourage HR to be actively included in those conversations, because these are conversation rewards.

Gordon:  That's one specific, concrete thing that you've just been discussing there around peer rewards, and peer recognition. One of the things we often hear about DevOps is, it's important to have top‑down support for a DevOps initiative. Imagine you're talking to somebody at company Acme, at executive level. They really will drive these DevOps thing within their organization.

A couple of questions. First of all, what might circumstances be at Acme that you just tell them you're not ready to start today? Conversely, what might be some specific things that you tell them that you then really need to put in place, so that you can have a successful DevOps initiative?

Jen:  It's hard, because you have to ask that executive to be introspectful about what it is they're doing, and who they've actually employed. I would say, if you have an organization that is actively interested in withholding information from employees. I'm not talking like, "We're going to require this brand‑new company. We can't tell anybody right now."

If you're more like, "We have this important project, but we'll just keep that information to ourselves right now, and then surprise everybody later." If you're withholding information or not actively sharing what's going on, I would say it's going to be really hard for you to have success.

If you are an executive that speaks and acts inconsistently, so you say one thing to one person, and then something different to the next, is going to be hard to maintain a culture of trust, equally hard to maintain a culture of empathy, especially if you are pitting to people against one another for resources, money, hardware, anything that you could see would be needed to get their jobs done.

If you're not necessarily open to listening to ideas from people who report to you, or maybe you're close‑minded to change, as in somebody says, "Hey, I've got this idea," or "I think we might be doing this wrong," and you're not willing to even have the conversation, or you're threatened by that conversation, I would say probably this is not the right step for you.

Gordon:  What sort of change is at the individual level that really needs to be made, compared to what's more standard types of practices?

Jen:  Especially for the concept of trust and empathy, a lot of times, we as humans, struggle with the word "jealousy." We are so used to comparing ourselves to the other people around us. Like, "Someone's got a new car. I guess I should get one too," or "My friend got a new phone, I need to get a new phone too."

That's probably a really good place for an individual contributing to start is start thinking about jealousy, thinking about "Why did so and so get that job over me," or "Why did they get recognition and I didn't." It's definitely been a topic that I struggled with, when I was younger.

Certainly in my career, I was always wondering why somebody got a promotion over me, or why somebody got something that I, in the moment thought I wanted. What really helped me get over that whole concept was to set attainable goals for myself. The keyword there is "attainable." For me, it's not "I want to be CEO of company X, and I want to make half a million dollars a year."

It's "I want to go and pass a certification exam, so that eventually, I can get this promotion," or "Set a clear educational goal or personal improvement goal." One of my most recent goals is to work a no more than 45‑to‑50‑hour work week. What I do for that is, I keep an eye on how long I'm working during the week, so that I'm not exceeding that.

That's mostly so that I can also have personal goals that I'm trying to meet, or keep my work out of my personal life. Things like that, what that can help an individual to do is to, when you see somebody at work, "Hey, I have a co‑worker who is in a very similar role gets promotion." I say, "Gosh, darn it. I wish I had gotten that."

What I can do is look at my already written down goals and say, "Wait a minute. Here are the three reasons why that really wasn't what I wanted, because that promotion's may come with X number of additional hours and more responsibility. Yeah, maybe it will be coming with more money, but that wasn't part of my goal set."

Maybe I didn't have a goal to make more money in the moment. Having that pre‑written down listed goals, at least for me, it helps me to know whether or not, I really should be jealous or not. I shouldn't be like, "Oh gosh. I wish I got that job." In the situation in which I feel like I should, I was really was something that I wanted.

Jealousy, disappointment, all that kind of stuff comes with that. Then, I have to be really serious and honest with myself and just ask question, "What should I have done differently, so that I could have actually been that person who got what that other person wanted?" Honestly, these are not easy questions or things to work through.

It can be hard. Even for me, it's very hard for me to set those goals. I recommend that you find a friend or a mentor, or somebody in your field of profession. Maybe not necessarily directly as working at the company they're working on, because it might be harder to talk about things and blunt in real terms, if you're working at the same company.

Find somebody that you can talk to and help stick to the goals that you've written down, so you're not being lose about it.

Gordon:  You worked with teams, some of which have certainly been successful. I assume at various times in the past, maybe not so successful on projects. What are the characteristics that jump to mind as contrasting those two situations?

Jen:  I worked on things that has been complete disasters. I worked on projects that prevented any enhancements going to production for almost a year, which to me is a terrible situation to be in, when you're working with a company that needs to get enhancements into the product they're working on. They can't because of the technical situation you're in.

Even with that team, they were surrounded by just a tremendous problem, which is the reason why it took them so long. It was not an insignificant project to take on. There are two things that could have made them more successful. Technology today makes it a lot more attainable, which it perhaps was not back then. The first thing obviously for me is always teamwork.

I laugh, because every time I use that phrase, I always think of "The IT Crowd," and there is a section that I absolutely love. I recommend everybody go and watch it. Just type in YouTube IT Crowd team, team, team, and you will pull up that video. It's interesting to me, because I'm kind of snarky about it, the whole concept of teamwork.

I've also seen teams that can work together so well, that even when they're faced with a project that is absolutely going to fail, they still seem to make progress or still seem to recover from that failure, much faster than a team that had a failure, and was catastrophic to their work, their working environment, their work relationships, and everything that goes into it.

What I'd want to see is a situation where even in a failing team, it did not take them weeks and months to get back to those state in which they were working at before the failure. That they can just say, "OK. We failed, no big deal. Tomorrow is a new day. We're going to see how we can prevent that from happening in the past."

That teamwork, that trust, the empathy, the lack of finger pointing, is a critical component of success on projects. I had a second one and I cannot sip in my minds right now. perhaps we'll some back, if that comes back to me.

Gordon:  In the interest of Internet, top five list or top 10 list or what not, briefly, what are five things if you're thinking about starting a DevOps project? What should you should put in place today, tomorrow, next week, to make sure you're successful.

Jen:  For me, the number one thing would be to look into blameless retrospectives or pre‑mortems. What are you going to do, if something goes wrong? Have a plan before it goes wrong. Have a conversation before release. Say, "What are all the things that could be gulches, and come up with a plan to address them?"

A lot of times, project managers call those "risk analyses." It can be off‑putting when you call it a risk analysis, but do them. It doesn't have to be to the level that some project managers will do it. Have the conversation. It's probably a good idea to have that culture in place before something goes wrong.

Look into if you have a management structure in place that is firm, and there's not a whole lot of employee development going on. Look into training to see if there's something that you can do in your organization, to help guide managers in a direction that will encourage them to look at their employees as individuals, and try to change the way that you are mentoring people internally.

Individuals have a list of goals. Sometimes, those goals are going to guide you out of the company you're working at. That can be quite scary, but have your personal goals. Make sure that you know individually what it is that you are going to be comfortable doing, specifically in the case of...for me, sometimes when you are going into a situation, where you're saying, "I'm going to do "DevOps. My organization's going to be great." 

Sometimes, that comes with the reality of you're going to have to do the right thing. The right thing is not always going to be popular. Make sure you understand where your boundaries are before you get to that point, so is your boundary. "I'm going to do the right thing, until I get fired, because of it," or "I'm going to do the right thing until this point in times happens, and then I'll let it go."

Just know what your boundaries are as an individual. The final one is, make sure that you have a system in place to do some sort of awarding, some sort of recognition that is not manager down recognition, because manger down recognition if you're already having a problem with your managers, who are not interested in employee development. It's not that they're not interested, but they don't know how to.

It's going to be really hard to encourage a system of collaboration or teamwork, if there's no way for a team member to say thank you to another team member other than just saying thank you. Thank you's are great, but having some way to track. Even monetary words are great. Something is better than words. Those are my top five, right now.

Gordon:  Great. Thanks, Jen. Anything else you'd like to add in closing?

Jen:  Nope. That's it.

Carmen DeArdo of Nationwide talking DevOps

There’s a nice interview with Carmen DeArdo, DevOps technology leader for Nationwide Insurance, over at The Enterprisers Project. The whole thing is worth reading but here’s one highlight:

So a key learning is that while technology is great, if you don’t have an efficient end-to-end process that provides continuous visibility of the work as it progresses and also reduces variance, technology will only provide limited value to improving speed and efficiency of what you deliver to your customers.

This is an ongoing theme around DevOps. Modern open source toolchains do matter. But so does having processes that enable automation and provide continuous rapid feedback loops. (And, as Carmen mentions elsewhere in the interview, having the right people and culture is key as well. He says that "forming agile teams is a great way to start."

DevOps on the Red Hat Developer Blog

Monday, September 28, 2015

Links for 09-28-2015

Wednesday, August 05, 2015

Bluetooth beacons and the (potential) creep factor

GimbalS10 large

I’ve started fooling around with Bluetooth beacons recently. Here’s a story about how Target is planning to pilot beacons in a retail setting (which is one of the most common use cases:

 During Target’s testing period, capabilities are limited to surfacing deals and recommendations based on what section of the store a customer is in: A two-for-one deal on Tylenol pops up when a shopper hits the pharmacy, or a recipe for banana bread appears while walking through the fresh fruit section. Target has plans to add features like reorganizing a shopping list based on the most efficient route through the store, and pushing a reminder if you forgot anything on that list once you hit the checkout line, but these will not be available at launch.

Such applications seem potentially useful: coupons/specials based on the department, "I need some help now," etc. They can also start to inch over the line of creep even if, as is commonly the case as it is here, the consumer needs to install and enable a smartphone app to use the beacon services (and be tracked in the store). Imagine having your path through the store loaded into a database, correlated with purchases, your demographic information, and other information from third-party databases to deliver a "personalized experience.”

At one level I don’t worry too much and even vaguely regret that we’re generally pretty bad at targeting advertising anyway. From the comments of this Technology Review article on Facebook a few years back:

A well-known dirty little secret in the advertising world is that, even after millennia of advertising efforts, not a single copywriter can tell you with any confidence beyond a coin flip whether any given advertisement is going to succeed.  The entire "industry" is based on wild-assed guesses and the media equivalent of tossing noodles against the kitchen wall to see what might stick, if anything.  It doesn't matter whether it's print, TV, or on-line media, no one can predict what will actually work.  FB engineers are probably even less well-equipped intellectually than the average ad hack in being able to come up with a better mousetrap to get people to buy what sellers want to hawk.

That said, companies are often somewhere between mildly and completely oblivious about how consumers perceive targeted advertising and other forms of personalization. As Lisa Barnard of Ithaca College noted in a recent study

Previously, targeted ads were based on larger demographic descriptions, such as age or hobbies. But now, with personal information scattered across databases, marketers are able to create more specific consumer profiles. That's what consumers find creepy and what marketers are failing to consider, Barnard said. Even millennials, most of whom are digital natives, are bothered by this extreme customization, she added.

And take a gander at this clip from Minority Report. It may approach satire but I’ve seen perfectly serious “thought leadership” videos from tech companies that weren’t much different.

(For a different and wholly non-creepy example of Bluetooth Beacon technology that uses beacons as the mobile element of an application—they’re more typically used as stationary devices tied to a particular location--take a look at this writeup of a demo Burr Sutter put together for Red Hat Summit.) 

Links for 08-05-2015

Thursday, July 30, 2015

Links for 07-30-2015

Podcast: Soft skills for DevOps with Red Hat's Jen Krieger

Jen Krieger is an Agile Coach on Project Atomic at Red Hat. In this podcast, she discusses soft skills, such as communication, that help software teams work better together and reduce unnecessary conflict. She also talks about how software development, especially in open source environments, is increasingly physically distributed and shares some tips for making remote teams work more effectively together.

Show notes:
MP3 audio (17:06)
OGG audio (17:06)

Monday, July 20, 2015

Links for 07-20-2015

Friday, July 17, 2015

Links for 07-17-2015

Friday, June 19, 2015

Where's podcasting on the hype cycle?

Says Farad Manjoo at The New York Times:

So don’t call podcasting a bubble or a bust. Instead, it is that rarest thing in the technology industry: a slow, steady and unrelentingly persistent digital tortoise that could eventually — but who really knows? — slay the analog behemoths in its path.


I’m not sure about the ultimate result, but steady progress in podcasts seems right to me. (And, while a possible bubble in podcasting ad rates is a legitimate and serious question for those directly involved, I’m not sure it’s a terribly important factor in the overall development of the medium.)

Here are my own experiences and observations.

The hype around podcasts initially was enormous—THEY’RE GOING TO KILL RADIO OMG! Yet, a lot of that first wave of podcasts was pretty horrible and self-indulgent. LISTEN TO ME! I’M PODCASTING AS I DRIVE TO THE GROCERY STORE! At the same time, it was a laborious (or at least rather manual) process to get podcasts onto an iPod. Pre-smartphone, syncing things to a mobile device was a pain. It’s why I, like many others, got tired of trying to sync that gadget of the moment, the Palm Pilot, to our calendars in a previous technology generation.

In no particular order, here are a few ways in which today is different.

We have smartphones. While I often find syncing isn’t as automagical as I might like it, it’s really not bad—especially if you’re somewhere that has cell coverage.

Even leaving aside the enormous popularity of a show like “Serial,” there’s a solid line-up of professionally-produced shows from a wide range of outlets. NPR shows have some of the most consistently high production values overall but...

Even leaving aside those shows assembled by a professional staff, there’s a solid stable of podcasts with clean sound and interesting content, whether niche or of more general interest. Interviews are one common format but hardly the only one. I think it’s fair to say that we’ve collectively gained enough experience with the format that a lot of people have learned how to put together engaging episodes without investing thousands of dollars in gear or spending way too much time in post-production. 

There’s probably still an ongoing shift toward more people consuming multimedia, rather than printed, content. Video gets more of the press here. But I’m at least willing to listen to the argument that the amount of listening may be increasing at the expense of reading.

Another trend that would clearly seem to apply here is a secular shift from listening (and watching) whatever happens to be on to deliberate on-demand choice. (And decreasing incremental effort associated with on-demand—think DVRs vs. VCRs—will only reinforce this change.) 

Don't Skeumorph your Containers from DevOps Summit

Here's my presentation from DevOps Summit in NYC last week. When I get a chance I'll put up some sort of video but this should work as a placeholder until then.

Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as applying more broadly, to applying existing patterns to new technologies that, in fact, cry out for new approaches. In this session, Red Hat’s Gordon Haff will discuss why containers should be paired with new architectural practices such as microservices rather than mimicking legacy sever virtualization workflows and architectures.

It’s far more fruitful and useful to approach containers as something fundamentally new and enabling that’s part and parcel of an environment including containerized operating systems, container packaging systems, container orchestration like Kubernetes, DevOps continuous integration and deployment practices, microservices architectures, “cattle” workloads, software-defined everything, management across hybrid infrastructures, and pervasive open source as part of a new platform for cloud apps.

More discussion of containers at

Tuesday, June 16, 2015

Open source, turbocharged pace, and cloud

As usual, Adrian Cockcroft has smart things to say in this interview. The whole thing is worth reading but this comment on the pace of change particularly struck me for a couple of reasons.

And we’ve got now a very open-source world that’s moving extremely quickly. Although it’s not strictly cloud as such, the Docker ecosystem is one of the fastest-moving environments that we’ve ever seen. It’s unprecedented how fast it’s moving. About once a week there’s a seismic event where they change it; a Nepal earthquake-size thing happens on a weekly basis, where you have to say, ‘Okay, everything you knew is slightly different.’ So just trying to track what’s going on in that ecosystem is more than a full-time job. And it’s confusing. It’s also very interesting, and the ability to get things done in that ecosystem is evolving extremely quickly. If you say, ‘I can’t do this thing with Docker,’ you’ve got to time-stamp that. Because maybe next week you can, or maybe in a month everyone’s doing it. Things that normally take years are taking more like months.

The first reason is that Adrian is, of course, absolutely spot-on about how quickly things are changing. I’m a bit embarrassed to admit that the cloud book I published just a couple of years ago now has major holes in the topics that it covers. While many of the basic concepts and their historical antecedents remain valid, containers (to choose the most glaring example) are wholly absent along with all the associated packaging and orchestration work in projects like Docker and Kubernetes. While "It’s the future" is mostly intended to be humorous, it also makes a certain serious point about the rapid swizzling and roiling of software stacks happening today.

Adrian also observes that all of this is happening within a largely open source environment. I’d argue that the rate of experimentation and advance wouldn’t be remotely possible otherwise. All the things coming together around containers and hybrid clouds from DevOps to microservices to internet-of-things to platform-as-a-service are fundamentally made possible by the rapid innovation and ability to recombine software that open source makes possible. It’s no coincidence that we’re seeing this Cambrian explosion taking place in an increasingly open source-anchored and dominated computing world.

Podcast: Nulecule and Microservices with Red Hat's Mark Lamourine

In spite of their popularity at some Web "unicorns" like Netflix, microservices are still in their infancy. In this podcast, Red Hat's Mark Lamourine shares his experiences to date with microservices in addition to offering his take on recent discussions about the best way to get started.

Listen to MP3 (0:18:06)
Listen to OGG (0:18:06)


Gordon Haff:  Hi, everyone. This is Gordon Haff with Red Hat. Welcome to another edition of the Cloudy Chat Podcast. I am here with my colleague, Mark Lamourine, who you've heard before on these podcasts if you're a regular listener.
Today we're going to get back into microservices because Mark has been talking to a lot of people and doing some exploratory work in microservices. There was also an interesting blog post that came out recently from Martin Fowler who many of you probably know. He's written a lot about microservices. It's an interesting topic to discuss.
We are also (by a path to be determined as we go through this podcast) then going to talk more about Nulecule, about which I produced a podcast with John Mark Walker a few weeks ago.
Mark is going to dive into a little more of the technical details of Nulecule and some of the ways that Nulecule relates to other projects out there, and other things that we've talked about on previous podcasts. Microservices. What have you been learning about?
Mark Lamourine:  Actually I've been helping our marketing department talk about our point‑of‑view [around microservices]. In those discussions I'm learning some of the misconceptions people have and some of the ideas they're floating.
The concept at its highest level is pretty simple, that you take tiny components and you create them in a way that makes them very atomic and mobile. Then you use them to recompose bigger services. We've been doing that with host‑based stuff for a very long time. You put the Web server and you put the database server on the box.
In some senses you can treat each of those conceptually as a microservice. The new idea is that you don't need to put them on the same host. You can use containers. You can use VMs. You can use various other things so that these really become composable in a way that a host‑based system hasn't been until now.
Gordon:  You've been doing a lot of talking about them. Has your thinking changed at all?
Mark:  Most of the thinking that's changed has been around trying to formulate ways to express how microservices are supposed to be used. We're still early enough in it in the same way that we are with containers, that people go off with fairly simple concepts of what a microservice architecture means.
But people are misled by hype. They might jump into something that maybe they're not ready for, or maybe they dismiss it because they say, "Well, I've heard about that before." Then I think a certain amount of education is necessary for people to be able to make good judgments about when a microservice is appropriate and when it's not.
Gordon:  This is probably a good point to jump into talking about the Martin Fowler post recently. The simplistic headlines—and headlines are nothing if not simplistic--had him saying, "Oh, just build a big monolithic application to start with, and break things apart down the road." That's not really what he said.
Mark:  It was his headline. It was the hook that got people to go look. If you read the article more carefully, what you find is that he's repeating things that have been said to him. He's repeating observations that other people have made and that he's made to a certain degree when looking at both successful and unsuccessful new architectures.
That people have been more successful so far pulling apart monolithic systems, and re‑implementing them as microservices than they have been at creating new microservice systems from scratch.
Gordon:  That's partly because it's hard to figure out what service boundaries are, for example.
Mark:  I suspect that there are a lot of reasons. If you follow the article, one of the things he says is he's not quite sure why this is. The observation is there. Why? He leaves it "We don't really have any deep data." This is really fairly anecdotal, and it's his impression.
A couple people have commented that his impression is going to be shaped by what he does. That's his job. His history is going in and re‑factoring things that have been built a certain way and have problems. He looks at them and he figures out how to bring sanity to them. That fits the microservice model.
The jury is still out on whether people understand the characteristics of microservices well enough to start from scratch building the microservice architecture. I have my suspicions about why. My personal suspicion about why people would have problems with that is a bit of hammer‑and‑nail psychology.
If you're a new adopter of microservices, you're going to try to make everything a microservice, and that might not be the appropriate thing to do if you have two or three things that in fact work together tightly bound.
Gordon:  Certainly there are organizations that have really, really gone all in on microservices, the kind of thing that's Amazon. "Everything will have a public API or you'll be fired" or the Netflix approach.
I suspect you get under the covers of those organizations, and even there probably everything isn't quite as purist perfect as the public perception is. However, they really had the opportunity to start with largely clean sheets of paper.
Mark:  That's true. I'd have to say if I were to go looking at those and find the places where the purity hasn't been maintained, if that's the right thing to do then that was probably the right thing to do. That was the point I was making earlier.
When we started with object‑oriented programming, suddenly people who thought that object‑oriented programming was the most wonderful thing, everything became an object. We got decomposition nightmares of everything is an object down to creating your own int type just because, "Well, it should be an object in languages like C++."
That's what I meant by the inappropriate use. That's what I'm afraid of in some of the microservices' first attempts. I suspect people at Amazon fairly quickly started learning where the boundaries of appropriateness were. If you go look, I suspect you'd find that.
Gordon:  The fact is that with first system you always need that to learn. Of course then what you do is you build the second system, and you throw too much new stuff in. Nonetheless you still need a learning experience in some way.
Mark:  If you follow Fowler's article all the way to the end and you look at his last paragraph, that's essentially what he says. He says, "This is really still too young." These are wonderful observations.
These are important observations, but this field is still really too young for anybody to be making strong claims because there's just not enough data yet to support strong claims either way about what's the best approach when you're starting from scratch.
Gordon:  Just to throw in one last comment in the programming‑language front, you mention C++. Obviously there's an aspect of object in most modern programming language at this point.
On the other hand it's probably worth noting that some of the more academic really ultra‑pure everything‑has‑to‑be‑an‑object languages that were out there in some of the early days, most of those probably can't even remember their names any longer.
Mark:  I can, but [laughs] I don't think most other people can. You don't see them in common use anymore. You don't see Oberon in common use. You don't see Modula‑3 in common use. You don't see Smalltalk in common use. That's not to say they're not used in production in some places. They're just not as widespread as, I have to say, more practical languages.
Gordon:  We've been talking about the things that run in containers, for example, so the development side of things. Let's switch gears and talk about what's going on with the management and orchestration of those containers.
As I said I had John Mark Walker on here two or three weeks ago introducing the Nulecule specification. Let me make one thing clear at the beginning as I think this has sometimes caused a little bit of confusion over the last couple weeks.
Nulecule is the spec, and Atomic App is the implementation of that spec, Atomic being this container‑based operating system that is optimized to deliver containers. Let me give you a shot at explaining a little bit about what the purpose of Nulecule is and how it relates to some of the other things out there.
Mark:  We've talked before about a lot of the pieces that we're building with respect to containers and various other relatively new available technologies. I see the Nulecule spec and the Atomic App implementation as yet one more layer. Docker itself is like the initial processes. You can create one. You can type a command, and you can create one. It's a great little process.
Kubernetes and OpenShift are ways of creating more than one of these things in an automated way and maybe distributing them across a platform. In both of those cases you're still managing them one at a time or maybe in small groups.
What Nulecule does is it adds the next layer of abstraction where, instead of describing individual processes and then how the individual processes communicate with each other, you describe instead a composed service.
I've been working specifically on one. I've been trying to implement the Pulp service as a purely containerized service without using any of the orchestration beyond Kubernetes so that when I get that nice and stable we can apply the Nulecule spec and turn it into an Atomic App as an initial demo.
I picked Pulp early because it's the smallest application I could think of that had all the elements that you needed. It has a database. It has a messaging service. It has storage. It has external networking. I've gotten that to the point where I can start that up at Kubernetes with a shell script.
I run the Kubernetes commands manually by a shell script. The parts are set up so that they self‑assemble. They don't require sequencing. Now that that's robust I'm going back to the Nulecule guys or the Atomic App guys and saying, "OK, how do we describe this as a single application?" That's really the point of Nulecule.
Nulecule is that next layer where you describe an application as a whole, and you hide the components again. You only provide the variables that you need to make each particular instance of the application.
Gordon:  Nulecule and the Atomic App actually makes use of container technology itself, right?
Mark:  It does in a way that actually surprised me when I understood it. I assumed when I was talking about scaling that you'd have a service like Kubernetes. Then you'd have another big uber‑service over the top of it.
When I understood what the Nulecule spec was, it took me aback. Rather than being some uber‑service, instead it's a way of expressing the complex relationships of your application, but you actually stuff that knowledge into another container.
Traditionally right now, tradition six months old, if you were going to create a complex app with Kubernetes, you'd create a bunch of pods. You'd tell them how to talk together. When you get to an Atomic App, you'll have one container. You'll say, "Start that container, and here are my variables."
It will talk to Kubernetes and act as the agent that causes all of those other components to come into existence. You get to treat your application as one container when in fact it's going to be running some large number of potentially scalable containers without a central service monitoring it or without the need for it.
You could layer that central service on as another scope if you want. Nulecule's an interesting term because it implies "Molecule," which is a composed thing of multiple atoms.
In that sense if the Atomic App is a molecule of your app where the database is one atom and the Web server is another atom and the messaging service is another atom and together they form some complex compound, that does something that you couldn't have imagined by looking at the pieces.
Gordon:  I did want to clarify again one other point here, with you mentioning Kubernetes. Kubernetes is the orchestration that we do specifically use in Atomic App. That's the orchestration provider of choice in Atomic App, but the Nulecule spec itself is actually orchestration agnostic. You can specific different providers there if you choose so.
Mark:  In fact there are three implemented now. Kubernetes is the one we're using most because we're also trying to beat up Kubernetes and learn more about it and then harden that. You can also just use plain Docker, or you can use OpenShift as the backend provider. The goal of the Nulecule spec is to allow you to hide that.
You pick which one. You specify your application, and you let the Atomic App manage whichever provider you ask for. If you use the Docker provider, it's going to call Docker commands directly. You have to run it on a single host. Essentially you get a stand‑alone Pulp service in this case.
If you use the OpenShift provider, you'd get one that runs in OpenShift. If you use the default Kubernetes one, you get one that Kubernetes manages the components.
The goal is that once you've created your Atomic App, if it's done well, all the user has to do is select the Atomic App, provide a few variables ‑‑ the host name for their service, what the public IP will be, and how to provide things like security. What are the keys, the non‑reusable parts? Then your service appears.
That's a bit rainbows and unicorns at the moment, but that's actually what we're shooting for. I don't think it's out of reach in the next few months.
Gordon:  This is really very consistent with the philosophy that we're taking in this whole space. If you're an enterprise and want to do DevOps, want to do actually development, want to enable developers with self‑service, you can just buy OpenShift.
Essentially that's taking care of an awful lot of the container management and application scalability using these various components for you.
If you do want to assemble your own homegrown implementation, although surveys we've been doing recently really do show people tending to move away from that and towards just getting a platform service that bundles all this stuff up, but you can certainly do it.
That's all open‑sourced. There's communities associated with all of these. If you want to roll your own and you want to combine different things in different ways, you can absolutely do so.
Mark:  As somebody who works on the community side a lot, I actually encourage that. I'd much rather see a rich community environment where people are experimenting with ideas, trying them out. Like with everything else, 80 percent of everything's going to get thrown away, but if you don't try you never get the other 20 percent. I want that other 20 percent.
I expect that we're going to see a lot of evolution of both products and concepts certainly over the next year or two and very likely over the next five years and decade. Science fiction is happening.

Which direction it'll go I can't predict, but I've got a few ideas myself about things that I think might happen. I can't make them happen yet because there's a big gap between what we can do now and what I can imagine. People are imagining, and this is a pretty cool time.