At a time when it seems containers and microservices are practically all everyone is talking about, it’s easy to think they’re a no-brainer solution to so many development problems.
But it’s not that straightforward. I spoke recently with Scott McCarty, an evangelist and “container thought leader” at Red Hat. Why wouldn’t someone user containers? It turns out there are several compelling reasons. First, not every application is container friendly.”Will my app fit in the container and will it be able to run in a relatively sane way?” McCarty asked. Containers require the operating system to be broken in to two pieces so an application needs to be able to handle that, McCarty explained. “Some apps just weren’t meant to be divided in to two.” And then there are what McCarty calls the “edge cases” which are apps so large and so dependent on, say, an Oracle database, that it’s just not feasible to port them in to containers in any kind of reasonable time frame.
Security is another significant concern, according to McCarty. If you can break the app down in a way that makes it work in a container, you’ll get a good bit of built-in security, he said. But if the application can’t be divided correctly, “you don’t get those security codes for free and the value proposition is really limited.”
Can we do this?
But there’s a third, surprising, reason companies are not choosing to containerize and that’s because they’re afraid they don’t have the internal talent to pull it off, McCarty said. “Do I have the talent to do this? Are we we even prepared to do this? Will I be able to hire the talent to do this?” And apparently this is a real concern, not just because of the worldwide shortage of software developers but because an explosion of tools and choices has meant each developer has the opportunity to do it his or her own way. But will they do it correctly, with so many choices? “That’s really the issue,” McCarty said. “Will they choose the right tools and will they be experienced enough to make it happen?”
What’s holding you back from moving to containers?
Is the role of enterprise architect changing? It is, and it isn’t. I know that’s helpful.
I recently spoke with Todd Loeppke, CTO Architect for Sungard Availability Services, a company that is focused on IT production and recovery. He has a broad view of the changing EA role, thanks to his many client contacts.
From his vantage point, the EA job itself really hasn’t changed but the pieces and responsibilities are changing and in some cases, quite dramatically. “If the IT architect’s job is to architect IT solutions that solve business problems under a big umbrella then the role hasn’t changed,” Loeppke said. “But the parts, the experience, well there’s pretty much everything under the umbrella that’s changed.”
Loeppke thinks the tricky part is that the tools an EA is using have changed completely and, of course, there are more tools. Take automation. The idea that so much should be automated in this DevOps world we live in is a huge change and something today’s EA is now forced to deal with. “Automated testing is taking over, and it has to,” he said. An EA today “is going to have a greater sense of automation than ever before. This was not a sexy practice in the past but it is key to success in the future.”
But it doesn’t stop there. Loeppke says an EA today has to have a broad view of open source tools — and if you’ll pardon the pun, be open to using them. It’s ok to reach out to GitHub and see how other people have solved a problem.
And while the nature of an enterprise architect job is to be a generalist, don’t plan on being too general, or you’ll run the risk of missing something, whether it’s security or cloud or networking related.
Sounds a bit like same job title but a different playbook. How do you think the EA role is changing? Let me know.
Andreas Grabner, a “performance enthusiast” who works at Dynatrace, understands that metrics are the holy grail of a DevOps team, but he also knows that the information can be hard to come by on the Devs side of things.
Speaking recently at DevOps Days Boston, he was clear about what developers need: “Metrics should be put in your face.”
In fact, he recommends installing ceiling devices that can go from green to red so that devs can know instantly if a build isn’t working. Spinning red overhead lights can go a long way to drawing attention to a problem, right?
And it’s really not about automation, he said, because automating bad code does nothing for anyone. The key is to find a way to bring data to the developers right where they are.
“A developer is 100 percent responsible for the code,” Grabner said. “The code runs on the framework and if you don’t use the analytics tools you have you won’t know what’s going on. With a metrics-driven pipeline you get better code from the beginning.”
You don’t have tools, you say?
Ah, but there are so many out there, many available free of charge for personal use.
Want to tell us what your favorite go-to analytics option is?
“To some extent Agile isn’t a solved problem.”
“Agile needs to freaking grow up.”
“We need to stop calling it Agile.”
“We need to stop saying Agile makes it easy to go faster.”
“Agile got us going, but DevOps is going to take us where we need to go.”
In the conference rooms of Agile 2016 in Atlanta this week, there was a lot of talk about where Agile is today. At 15 years old, Agile, in one sense, is maturing and going strong. But, even among those who preach it – and make a living from it – there is just a hint of unease when it comes to talking about the future.
Nowhere was this more obvious than during the session “2020: The State of Agile.” Moderated by Jann Thomas, a former developer, with three Agile coaches as panelists, this session was standing room only. But, as the session progressed, more and more people started to leave. The issue, it seemed to me, and in discussion with other attendees later, is that people were looking for a practical road map for Agile’s next few years. They wanted to hear, head on, how to tackle the challenges. What about new technology, what about DevOps, what about the fact that this can be so very difficult to get right?
The panelists were clearly frustrated with Agile’s “reputation” but their solutions were cosmetic in nature. One suggested renaming Agile (“it’s tainted” by folks who couldn’t do it correctly), and then offered up a slew of catch phrases including “bring your femininity to the job,” allow “openness and compassion,” “speak from your heart” and “bring your vulnerability.” At this point, a lot of people were leaving and one man raised his hand and suggested his CEO simply wouldn’t want to hear those things. There was nervous laughter at that.
And when the group did try to get a bit more nitty gritty, they suggested de-coupling Agile from speed of delivery. Don’t focus on faster delivery, focus on “sooner.” Is there really a difference here? They insisted there was but I am still not so certain.
This session left me – and many others I spoke with – feeling deflated. Change is coming, whether it’s via the Internet of Things, the cloud, or DevOps. Change doesn’t have to mean the end of Agile – after all, it’s quite diluted already given the thousands of different ways companies “do” Agile. But in order to roll with change, and grow from it, you need to acknowledge it. Agile needs practical and unfortunately for much of this week what we heard were platitudes.
It is, indeed, time for Agile to grow up and take the next steps.
Developers, slow applications are really not your fault. And I’ve got two examples to prove it.
And in the category of other things you have no control over, it’s time to bring Brexit in to the mix. While obviously the UK leaving the EU isn’t going to slow down your app, it may slow down your app development, particularly if your developers are in the UK. The European Union allows free and easy travel between member nations, something that’s translated in to a lot of software devs from other countries working in London. That’s helped ease the shortage and boost productivity, but things are changing, according to Robert Grimsey, director at UK-based recruitment firm Harvey Nash. “Brexit has created uncertainty,” he said. “We’ve seen it in the lead up to the Referendum, during which demand for recruitment across all roles – including software development – was down. Now that Brexit has been confirmed, our expectation is that demand for permanent software development roles will continue to stay suppressed until there is a greater visibility.”
What could that mean? More contract jobs, for starters, as companies may not want to hire permanent workers. And it could mean a hiccup — or ten — when it comes to development projects.
The bottom line: lots of things are out of your control, like third party apps and political upheaval. At a time when many are tired of hearing how the dev process is at fault, perhaps today we can all take a little (admittedly cold) comfort in the fact that we can actually identify a few of the culprits. It won’t last forever, but for right now we can try to enjoy it.
Yes, you read that title right. Too bad I can’t take credit for the pairing.
Way back when I worked for a daily newspaper, the most exciting times of all were of course the election cycles. The late nights, the meet and greets, the feeling of change in the air…good times.
It’s another election cycle — by all accounts a one of a kind cycle at that — and of course change *is* in the air still. And not just when it comes to politics.
I interviewed Will Evans, chief design officer at Praxis Flow, a couple of weeks ago. He’s a lean development expert, sure, but he’s also a fun and lively interview. I would guess his seminar at QCon was probably a lot of fun.
But Evans will always have a special place in my heart because in this election cycle he brought together two wildly different “things” and actually made it work: DevOps and Bernie Sanders.
“Imagine Bernie Sanders is the DevOps of politics — fresh ideas but fundamentally not changing the entire system,” Evans said. “People are idealists in DevOps. If Bernie can change the platform and shift the Democratic party to the left 5% that is progress but not perfection and DevOps is the same.”
Evans thinks the biggest problem in the software development arena is that people aren’t engaged and are at risk of spending their time doing things that don’t matter. DevOps, he believes, can be that change, but like Sanders, you have to see it as a process and and not an end result. “The promise of DevOps is to move things, to make things 1% better next year. That is meaningful. This is a long haul with a lot of hard work and we’re not going to have change overnight.”
Can we afford to be patient? I hope so.
Tell me how you think software development and the election cycle are linked.
Ask any application-development decision maker or programmer: Emerging technologies force enterprise IT shops to rethink not just which new products and services to adopt, but even more importantly, the very nature of how they do their jobs. For this reason, TechTarget’s expanding its coverage of IT operations with the launch of SearchITOperations.com.
Our long-standing attention to core application development technologies and buying trends — such as development ALM and app containers — will not change on the TechTarget coding and software websites you already read. Rather, through the new SearchITOperations, we recognize the cultural and technological transformation underway as IT operations and application development more closely collaborate to heighten their enterprise’s ability to respond to market changes.
Reaching into 2020
Looking out over the next three to five years, strategic IT shops will need to move beyond cost savings or avoidance, marked by silos and limited collaboration, to thrive. All aim for stable, flexible operations that are custom fitted to the internal landscape, corporate goals and business outcomes of that enterprise.
For many IT shops, the desire to facilitate shorter application release cycles without outages and mistakes means reordering staff, acquiring new skills and choosing from a plethora of new tools to automate tasks.
The new site is dedicated to the news, features, how-to tips and other expert content that enables IT operations pros to manage new application architectures and faster release cycles, along with the feedback loop concept promoted by DevOps. From our view, these tie-ins with AppDev teams are clear and important.
As always, our readers can expect unbiased technical information as they evaluate new tools, learn additional skills and plan tomorrow’s IT operations.
We hope you’ll check out the new resources on SearchITOperations, and we thank you for your continued loyalty to, and readership of, SearchSoftwareQuality.
My recent story on the surprise skills gap — writing, public speaking, communication and most decidedly NOT tech skills — has me wondering what it means to be the ideal employee. The term “well-rounded” is tossed around a lot, but what does that actually mean when it comes to testers and developers?
I went to a liberal arts college and, all right, I’ll admit I was an ENGLISH major. And not just any old English major — my degree was in 19th C. British Lit. Yes, my father was certain I would never get a job with a degree like that. He was a CPA and his view was that college was supposed to give you a marketable skill or, even better, skills. I obviously didn’t get “skills” but I did get an education.
That was a million years ago, and the world has changed a lot. Just this week I had a reader mention that he literally keeps his developers “locked in a back room” because they are completely unable to communicate — orally, or by email — with his customers in any way that resembles “standard” English. I did not get the sense that his developers were non-native English speakers; instead, it seems they just don’t have good communication skills, which of course brings me back to that skills gap.
So, to be an ideal developer or tester today you need: tech skills, of course, but you need to be able to write, speak and interact comfortably with customers and business people, and then you may need that “extra” something that involves, say, industry experience. That’s what Matt Sigelman, CEO of research firm Burning Glass, refers to as “hybrid skills.”
In other words, I think the bar is getting set at a higher and higher level as time goes on. There are straightforward solutions if you have an employee with insufficient tech skills; but Dale Carnegie and The Toastmasters aren’t exactly household names any more (click on the links if you actually don’t know who/what they are!) and as far as hybrid skills go, a hybrid developer creates him/herself by choice. The employer doesn’t have much to say about that.
So how do we solve that skills gap? Does your company have a strategy that’s worked? Or do you think the problem is overblown? I’d like to hear what you think.
Suddenly, in mid April 2016, everyone, and I do mean everyone, is talking about DevOps. They’re talking about Agile, too, of course, but unless I’m imagining things, it’s DevOps that seems to have captured everyone’s attention.
Last I looked, DevOps adoption was hovering at a (more than likely optimistic) 20% or so in mostly companies that self-identified as digital disrupters (in a survey of 1442). But now…it’s ALM and DevOps, it’s DevOps and security, it’s DevOps DevOps, Devops, oh, and Agile too.
So when did Agile become so last week? SearchSoftwareQuality columnist Jenn Lent, in her end of 2015 column, predicted this might be the year when Agile actually grows up. Seems it might have grown up so quickly that’s it’s morphing in to that next thing.
Is this bandwagon jumping, or is this real? I asked the last CEO I interviewed, who is rolling out a new product aimed at the DevOps market, just what kinds of companies he thought were going whole hog for DevOps. His answer: large companies and startups. Hmmm…those are the same kinds of companies still doing — and working on — Agile.
Another source I talked to a few months back was actually laughing about DevOps. To paraphrase, he said he felt Agile had already upset the apple cart for testers and developers and asking them now to take the HUGE step and embrace DevOps? Crazy talk.
And then there’s the CEO of Shippable who didn’t hold back…he straight up hated developers. Until he was one. And he still thinks the way DevOps is implemented is ridiculous. He calls it a whole “Kumbayah” thing.
But, he’s also got a product focused on making DevOps easier to implement, so he obviously believes in the concept.
So let me ask you — is the DevOps train coming by your town? And what’s happening with Agile while that happens?
It feels like change is coming. What do you think?
According to a new survey from NGINX, our apps are performing very badly indeed. And perhaps what’s worse news is that a whole lot of companies really aren’t doing anything about it.
NGINX did an in-depth survey of 1800 IT professionals on a variety of topics and it turned out there were several surprises, according to Peter Guagenti, chief marketing officer of the company. He said he was very surprised to see how widespread use of containers and microservices were (close to 2/3 surveyed were either already using or seriously exploring containers and nearly the same percentage was true for microservices).
But what absolutely shocked him and his team was the data on performance. According to the survey, app performance was a significant issue for 75% of respondents — they reported their app was either somewhat or extremely slow. Ok, that’s not good. But what’s worse was the fact that one-third of survey takers said their companies were doing absolutely nothing about it. Wow, nothing? (If you don’t want to be one of those ignoring performance, here are 19 ways to make your pages load faster.)
We know that slow applications cost companies tens of thousands of dollars, at least, in lost revenue as users get fed up and head to a competitor or just give up in general. “Not paying attention to this is the modern day equivalent of not paying attention to customer service,” Guagenti said.
On one hand, Guagenti said he can empathize. “What’s really going on here is the constant push-pull. Most organizations are understaffed. They need to build new features and the entire process is targeted at creating new features and not maintenance or performance tuning.” What ends up happening, he explained, is that companies become unwilling to go backwards.
And that’s how apps end up performing badly. What do you think companies need to do to fix this?