Category Archives: General

Tech Research References Online

Background

Here at Ingrained Tech, we spend a lot of time researching trends and data. Since more than half of our business is in technical writing and technical marketing, solid research data to back up our conclusions is pretty essential. The thing is, we’re not a huge org that can slap down thousands of dollars to pull one graphic out of an analyst report, so we spend the time digging for free data. Recently, it occurred to us that you all probably have a use for some of these data sources too. They range from developer tools to broadband penetration to DevOps trends, some of them are analyst reports that companies are offering, most of them are not. Some of them (duly noted) are behind a registration wall. We do not include garbage research, and filtered this list accordingly, though what your focus is will determine the value of any given bit of research. So we included quite a few.

Lend a Hand

Of course we don’t know all the sources available, there are just too many. We also didn’t hold this post back by making certain we had all of our great references in one place, so we’ll be adding some over the next week or two.

How best to organize the list in a blog post has been a bit of a conundrum for us. We finally settled on alphabetic order with a note of (registration) to delineate those that require you to cough up info. We’ll discuss a longer term strategy if there is enough interest to warrant more work. One thing we kept to a minimum was inserting our commentary. If more context would be worthwhile, we’d like to hear that also.

If you have a reference that you like to use (must include data, and a dataset large enough or specialized enough to have meaning – most of us don’t care that one vendors’ five customers prefer that vendor, no matter how pretty the report), please send it to us, we’ll check it out, and if we agree that it’s a cool source, we’ll add it to the list also. You can submit them to webmaster (at) ingrainedtech (dot) com, and we’ll get right on it.

Enough talk, here’s the list (created 3/9/2017)

Boston Consulting Group IOT Market

Developer Economics – State of the Developer Nation Q3 2016 (registration) Dense, but packed with info about development trends on different platforms.

ESG Blog – Cybersecurity Skills Shortage. The ESG blog actually offers some data points in many of their blog entries, so worth looking at other posts.

F5 Networks – The State of Application Delivery (registration wall) Full disclosure. Our founder is a former F5 employee, and his wife is a primary author of this report. But the report is packed with real world data from a large sample of F5’s customer base.

FCC Broadband report 2016

G2 Crowd IDE ratings  – G2 Crowd has many of these ratings, all worth a read.

IDC Worldwide Data Center Automation Software Market Shares 2015 – ( direct link PDF on VMware’s site, published June of 2016)

IT Central Station Application Delivery Controller Ratings  – IT Central Station has many of these ratings, all worth a read.

MesosSphere – Apache Mesos Survey 2016 (registration)

Netcraft web server survey

NetMarketShare trends in internet technologies

Pew Internet Usage 2015 by different stats (Age, Income, etc)

Puppet – State of DevOps Report 2016 (registration) As technologists, we weren’t terribly thrilled with the direction the 2016 report went, but included it because other years have been great, and assume this was a one-off problem. And there are still a couple of nuggets in the 2016 report.

Rebel Labs Java Web Frameworks Index

RightScale – 2017 State of the Cloud Report (registration)

Tiobe Programming Language Index

Xebia Labs Periodic Table of DevOps Tools

Let us know what we’ve missed, and if you find this helpful. We’re spending time on this that could be going to paying customers, so before we invest further, we of course want to know there is a need out there.

Thinking of joining a startup? One view of that world.

160318-news-silicon-valley Those who are regular readers know that I’ve spent the better part of the last two years at Provisioning/DevOps startup StackIQ. Last week that engagement came to an end.

I was knee deep in building Ingrained Tech when someone I trust called and told me “You have to check out my new gig. You’ll be impressed.”

I was. Even though I had clients and things were going well for Ingrained Tech, the idea that I could sit down and, using StackIQ’s tools, deploy a functional big data or cloud infrastructure in a short time, skipping all of the crazy “Oh did you forget to set this value in this specific config file?” It was an astounding piece of software, with founders that knew what they were doing.

So I jumped. I apologized to my clients, wrapped up existing contracts/work, and took the position. As happens with all startups, my role was broader than my comfort zone, and that was one of the things that appealed to me – after all, I was running Ingrained Tech, so what needed doing I was happy to figure out how to do.

I’ve worked in an array of startups in my time – from doing firmware for cell phones to CIO of a GIS startup – so I knew what I was getting into. And when I got the call that I was laid off, I realized I’ve never discussed the experience of startup work here on the blog. So I thought I would, because many people go into it relatively blind.

To be clear, StackIQ, and their open source project Stacki are still around, and will continue. The change was in needs of the organization, which happens in a startup… But we’ll get to that.

The first thing about working at a startup that you should know is that large parts of HBO’s Silicon Valley are real. Every startup I have worked for has been a collection of people trying to balance a conflicting group of audiences (investors, employees, big customers, average customers, contractors…), and all of them were doing so with an eye on funding, because that is the lifeblood of a startup. The longer you have to get the word out, the better your chances of succeeding. And every startup I’ve worked for truly believed in their product. Perhaps I’ve been fortunate or careful, but every startup I’ve worked for had good reason to truly believe in their product. The market and those competing constituencies on the other hand, not always so much to believe in.

If you’re considering going to a startup, others have said it before, but it cannot be said enough – expect to do new things. Indeed, expect that what you’re hired for may not be what the company needs at the moment, and you’ll be doing something completely different. There is good in that. For one, you’ll be expanding your skill set. For another, you are highly unlikely to get bored. And the final bit of good is the big one – you may carve out a new career in the process. By stretching beyond your comfort zone, you may find things you enjoy that you hadn’t considered before.

Since I was most recently at StackIQ, I’ll talk about it with them. This is already getting long, so I’ll focus on role change for the rest of this blog, and save the other things I wanted to talk about for another time.

When I interviewed at StackIQ, I was to be technical marketing/evangelist. Before I was hired, this was adapted based on company need (with my consent) to Solutions Architect. I spent my first week in sales training. This was definitely outside my comfort zone. I had trained sales staff, but no org had ever thought I needed to be trained, and as a remote employee, I spent a week between training sessions looking longingly over at engineering. The keys to the product and how it worked were locked away in engineering, but I understood I needed the sales info too, because it positioned us in the market, so I listened and learned (a lot, actually).

I spent the next six months doing sales support and working on demos that could be spun up at the drop of a hat. Anyone who knows about configuring the likes of Cloudera or OpenStack knows that “drop of a hat” is not something you generally associate with them. But we got to a point where we could show off the tool in those very environments (and more).

Then the direction of the company changed. The market we were in was limited, and there was a (correct, IMO) belief that there was more to do than simply spin up big data instances or cloud platforms. Both were interesting, but study after study was showing that they were not catching on as predicted, and the tool at our disposal could do so much more.

I spent May on the road talking about our big data products, then went home and moved away from solution marketing and more toward technical marketing/marketing/competitive analysis. Yes, for those working at F1000s, I do indeed know they are three different jobs. At some of the larger employers I’ve worked for the competitive analysis team rarely even talked to marketing except to deliver assessments of competitors. But startup land is different. You have jobs that need doing, and a limited staff to do them, so everyone does some. That was my bit.

I did take a bit of time last summer to make a whimsical newsletter for the marketing team that poked fun at the market we were in, while drawing out the strengths and weaknesses of different products. It started as a joke, and I kept the knee-slapping tone for several installments, but I like to think it helped solidify marketing’s view of the space. I had a lot of fun doing it, but don’t know that I ever would have shared it beyond the team.

The person who recruited me into StackIQ moved along, the primary product changed, I kept trying to alert the world to the benefits of their (our at the time) amazing bit of software. I have left the company, so there’s no reason for me to sing praises, and I’ll still tell you that if you install more than a couple CentOS or RedHat servers in a year, go get Stacki. It’s open source, so it’s free, and if you need support, of course StackIQ will sell it to you. It will make your life easier by automating installation of the base OS and configuration of the hardware.

So I stayed. I could tell the needs of the company were changing, but I stayed because I figured the product and its potential was worth the risk. And I pretty much knew the risk – if the needs of the company change too much, it makes sense to reorg and start doing things in ways that match the evolving needs. While I was willing to do what was needed, the company had to see to its long-term goals. I’m good with that – I even tried to resign for some of the same reasons a while back, though I didn’t want to, I thought it would be best. They asked me to stay, and I did to help the company through repositioning the model, but after this was complete, the company made some management changes and we agreed to part ways.

I could not wish them more luck. The product is solid, adjusting resource allocation may give them a chance to get the word out further, I truly hope it does.

Would I do it again? Wrong question, assume I would, since I’ve done it several times over the course of my career, and if you are not a regular reader, you likely found this post because you’re asking “Should I consider working at a startup?”. Well, in less than two years, I have added to an already large skill-set. Specifically, I’ve installed and used all of the server provisioning tools – stacki, cobbler, etc  – I’ve installed and used all of the app provisioning tools – Puppet, SaltStack, Ansible, etc – I’ve learned a lot about Business Development, I’ve written/managed different kinds of press releases, done slideshare in formats I had not before, and I met people that are either (a) Smart enough I would just learn from them, or (b) Nice enough that I consider them friends. I’ve had to work some long days, which comes with a startup, but I’ve had some light ones too – that comes with being part of a family, and in a startup is generally not begrudged. I’ve learned new ways to do some things in Python, actually installed and managed Jenkins (as opposed to just being a user), installed most big data variants, along with being one of the first to check out Chef Habitat… All in all, I’d say I got a ton out of the experience, and you would too, if you’re willing to work for it.

Enough of the good, how about the bad? Okay, it’s risky. I have known people that joined a startup in good faith and were laid off a month later. It happens, and doing your research won’t necessarily stop it from happening to you. Those options you’ll get promised? They’re not worthless, but they’re worth less than you think most of the time. The stock held by investors and founders and a few savvy C-level execs is worth more than yours. I’m totally okay with this, since without those founders and investors, there would be no startup jobs at all. But you need to be aware that if the investors are losing money, you are absolutely not going to get rich off your options. But this is just another risk, and one that can be managed a bit. Demand options, then don’t assume they’re worth much. If you’re lucky and joined a unicorn, they will be – far more than your salary – but for most startups, they’re practically worthless. When considering a job, consider those shares to be like most startups.

And it takes time and effort. I strongly recommend that either the people, the market, or the technology be so worthwhile to you that you’ll put in the extra effort. It is harder to drive oneself toward the success of a company that is counting on you if you don’t have one of those things to remind you why an hour or two at 10 PM might not be a bad idea.

Should you join a startup? If in your view the risk is worth the reward of helping to build an entire company, yes. If the people rock – are smart, or good people – yes. If the technology rocks – is solid and does what it claims, has room for growth – yes. But don’t do it for the pay – you’ll absolutely earn every penny of it – and don’t do it for the stock options, most aren’t worth the effort in startup-land (though if you’re a gambler, or truly believe in the product/people, this can be a positive tipping point instead). If you have the flexibility to join one, your horizons will expand if you approach it from a “what does the org need?” perspective. For some (myself included), this alone is worth the risk.

I would recommend yes in the case of learning, no matter who you are. But that’s me.

What am I doing next? Well stay tuned, I’m still deciding. My severance from StackIQ was enough to let me take a breather and figure that out, so I am going to. While returning to Ingrained Tech full-time is tempting, I want to make certain I’m choosing my direction, not letting it choose me. And in case you missed it, a lot of stuff in high tech interests me.

It is Not All About Changing Your World.

A funny thing has happened in the technology world, the hype cycle has become far more than a cycle that you watch and smile at. It has become a sales frenzy, while people try to make a name and/or sell you stuff before the idea or product category has even solidified. You can see it all around you, and as has been going on for years, the trend seems to be worsening.

I call it a funny thing because the truly revolutionary technologies – like server virtualization – really didn’t need a full-on hype cycle at all. Virtualization just kept growing year after year. People would declare “the year of virtualization!” and the year would pass, with more servers virtualized but no mass shift from one paradigm to the other.

I think it may just be time to consider that as long as the hype cycle is revving for a product or technology, it is not ready for prime time. My reasoning is pretty simple… As long as the hype cycle is in full swing, you will hear a lot of talk and not much implementation. Or a lot of talk that ignores the weaknesses that all technologies have.

The problem that drove me to this conclusion is that nothing is “A great solution for X” any more. They are all going to change your world! And I can’t speak for all of you, but for me that is problematic and counter-productive.

If you tell a CIO that DevOps really isn’t automation and standardization, but rather a redefinition of his role, his organization, and his employee’s roles, he sees risk. The same is true with the old “public cloud will change everything”. The problem is that “everything” is a big word, and it helps no one to hear it. I still recall laughing at the pundit that claimed there was no need for datacenters anymore because public cloud was here… But in all honesty, laughter was the wrong response. He scared a lot of people off, for fear that options would be taken away from IT. It took a couple of years for some to come back around to “right tool for the job” thinking.

To get an idea of the difference I’m talking about from the open source perspective, look at git versus OpenStack. People say “We use git.” on one side and “OpenStack will change the face of computing forever!” on the other. In fairness, OpenStack has made steady progress and is actually having average enterprises saying “we use OpenStack” these days, but from its earliest days, the hacks have been out there selling it as The Next Big Thing, whether it was ready or not. Git, on the other hand, has achieved astounding uptake precisely because it does one thing – manage code and similar files – and does it very well.

Truth be told, I suggest clients use VMware as much as OpenStack. Why? For a variety of reasons. Some because they have licenses, some because they have the skills, some because they do not have the skills for OpenStack. But when it comes down to it, both are just a way to better serve the business, and changing the world is not on most business users’ list of priorities.

Historically, corporate IT has been pretty good about sorting out the hype from the usable information, but this seems increasingly problematic. More orgs hopped on the “cloud everything” bandwagon than I expected (most only until they saw the TCO growth curve), and more seem to be biting on the “SDN changes everything” current hype.

Keep a cool head, look at what you can use and how it benefits, not what pundits claim the cool kids are doing. There is a ton of cool stuff going on, no need to grab the “this will change the world” thing unless (a) your world needs changing, and (b) you’re willing to invest a lot to change it.

High tech, though pundits hate it when people like me point it out, is like any other market. There will not be a world-changing shift of the seas, the world changing will happen slowly and visibly, as good products/solutions are recognized and implemented, word spreading about their utility and knowledge spreading about how to overcome their inevitable weaknesses.

And finally, remember that there is rarely One Ring To Rule Them All in real life. That’s why it’s a line from a fantasy book. Choose the right tool for your environment, your employees, and the direction you want to move your company, not the One Ring that some pundit is selling.

After all, if you’re like me, you’re using half a dozen technologies on pretty much a daily basis that were at one time going to change everything. And now they’re more reasonably positioned as tools to achieve results.

Product Roadmaps – from vendor to CIO tool

Thought I’d take a moment to drop a bit of an idea out there for making the most of vendor relationships.

You see, product roadmaps in the tech space are simply a sales and marketing tool. They are designed so that whomever you are talking to can point at them and say “those fifteen must have items? Look! They are coming!”

FakeRoadmap

How most of us really view roadmaps… 

But there is wealth in products roadmaps. We all view them with skepticism because we all know plenty of cases where the roadmap and reality didn’t mesh.

So the other day when I was telling a friend how to get more out of them than the vendor, I decided I’d share this tidbit with you all also. It’s really pretty simple.

When a vendor shows you the roadmap, ask for a copy. If this is the first time you’ve gotten a copy, ask for a road map from 12-18 months ago also (though they’ll claim they don’t have one, ask anyway). Create a location somewhere in your org – intranet, NAS, cloud storage, where ever – to store roadmaps, and drop what you have into a directory bearing the vendors’ name.

Then, you have an actual example to judge a vendors’ ability to deliver what’s presented in the roadmap. It won’t be perfect, there are a lot of things that impact product/feature development, but it’s far more than what you have now, which is skepticism. Comparing last years’ (or any old) roadmap to the product literature should give you an idea of how well they delivered. If it’s not in the feature list on the website, it’s worth asking if they have the feature.

Now you have turned the tables of the roadmap. Instead of a potential smoke-and-mirrors list of promises, you are using it to evaluate vendors’ willingness/ability to deliver. It gives you the edge in choosing solutions that are best for your organization, by comparing past performance.

Whenever a vendor meeting is scheduled, go out and look briefly at the roadmap, compare it to the literature on the website, go in forearmed with knowledge of what they said was going to happen and what did happen in the past.

I did this in the storage space while writing for Network Computing, and you find relatively quickly that size does not matter so much on delivery as other factors. And having the roadmap helps you understand which vendors – be they huge multi-nationals with decades of experience or tiny startups with just a couple of people – are more likely to deliver what they promise.

Of course, many vendors will be resistant to this intelligent use of their roadmaps. In fact, I didn’t tell them I was doing it when I was, because I worried they’d stop providing me this valuable tool. It is of course up to you how your org wants to handle getting and keeping copies of roadmaps, but it I heartily recommend doing so. Use the tools available, and avoid “we can’t do that yet” failures in your IT endeavors.

All-consuming, all-confusing.

Ask two politically opposed people in any given country about the causes of the country’s problems, and guess what? Each will give you an answer filtered through their world-view. Through what they know, and what they believe. That is not to say one is right and one is wrong, both simply see things in the manner their background and experiences tell them is right.

image

We definitely live in interesting times. Server virtualization has just about reached saturation, application development is going through a wide range of changes from the return of automated testing to continuous integration and the other facets of DevOps, SDN is the next wonder of the world, once we agree what exactly it is capable of and where it fits best, cloud didn’t conquer the world, and people are still building physical datacenters, yet cloud offers solutions to some problems. And all of this is changing while IT staff has increased security concerns, projects are still rolling in, and every new solution or system takes even more man-hours to implement.

If you ask a networking person – and I’ve had quite a bit of talking with networking people over the last few years – about DevOps, they’ll talk about automating network provisioning processes, SDN is either the greatest idea ever (software vendors), or the dumbest idea ever (hardware vendors). Ask them about cloud, and it’s all about the network functions – all of cloud’s woes are from utilizing a primarily (or singularly) software network, and the bright future of cloud is only possible if the network is completely redone to mirror historical networks.

Ask a systems administrator the same questions, and you will get completely different answers. SDN frees them from the network, cloud offers a good solutions to some problems, but isn’t likely to replace the datacenter any time soon, and DevOps is an opportunity to actually schedule time to automate things they’ve been meaning to automate for a long time.

And the list goes on. Process people think all of the above are about changing the culture. Security folks are getting involved in DevOps even though they’re pretty certain changes to things like firewall rules aren’t going to get changed without a human saying “yes, do that”, because more than jobs are on the line.

And do you know what? They’re all right, to some extent. The problem is that conflicting messages while IT is trying to figure out what all these things really are, and how a given technology can help them out can cause more confusion than the information imparted warrants.

So I’m going to spend a good long while here at my new blog home talking about all of the above. Not from the developer, or network admin, or systems admin, or process specialist perspective, though I have experience in all of those areas. I’m going to help you figure out what these technologies are, and how your organization can utilize them.

And I’ll definitely point out where they are unlikely to be of assistance to you. After all, that is one of the services we offer here at Ingrained Technology, and thus far, our clients have clearly told us “this needs to be talked about”.

And that’s enough for me.

Oh, and welcome to my new blog!

Looking for more? Try these links:

DevOps.com

SDN Central

Cloud Computing Magazine

Test Driven