Category: Ideas

Is PaaS Tech Still Around? Maybe Containers Will Kill it or Bring it?

Recently a post from @Gigabarb popped up on the ole’ Twitter that started a micro-storm of twitter responses.

This got me thinking about a number of things and I started to write her an email specifically, but realized I should really just blog it. After all, the topic is actually part of what should be the public conversation. It’s about the changing world of technology, which we’re all part of…

First Topic: Usage of PaaS

Barb, just shortly after the tweet above was posted, this other tweet altered what information I might provide her. @TheSteve0 had responded with some items, which @GigaBarb then responded with

Now, not to pick on OpenShift & Red Hat (the effort @TheSteve0 is working with), because they have a great open source effort going on around this PaaS Technology, but Barb had a point. If Cloud Foundry responded with something like this, she’d still have a point. The only companies that continually sign up new companies is AWS & Beanstalk (ok, so they don’t call it PaaS, it gets you to the same place – arguably better than most of the others), a little bit at Windows Azure and a few companies pop up every once in a long while that might take Cloud Foundry or OpenShift and run with it. Most of the early adopters are already on board and most that might get on board are still mostly just waiting in the sidelines.

This fact is frustrating for those

in the space that want to see more penetration, but for those that arent’ technically in the space, it seems kind of like ASP. Oh wait, I should add context now, ASPs as in Application Service Providers. The technology from the beginning of the 21st century similar in many ways to what is dubbed SaaS now. At the time it could have been revolutionary. However at the time nobody picked it up either. This is similar to what PaaS is seeing. However…

A Hypothesis of What Will Happen to PaaS Tech

I have a theory of what will happen to PaaS Tech, it is similar to ASP Tech. PaaS will keep plundering along in odd ways, and eventually one day, it will become a mainstream tech. Right now however it will remain limited. In that same turn, by the time it becomes a common tech, it’ll be called something else.

Here’s a few reasons. One, is that many developers see PaaS and their response, especially if they’re seasoned developers with more than a few years under their belt, is to respond will immediate apprehension to the tech. It removes key elements of what they want to control. It hides things they can’t actually get to and it abstracts in ways that don’t always make sense. The result is that many senior devs stay away from pure PaaS offerings and instead use it only for prototyping, but production gets something totally different. I’ve been there more than a few times myself.

However, the result of what most senior devs end up with, when they get their continuous integration and development environments running at full tilt, is exactly what PaaS is attempting to promise. There are some companies, with senior devs, and extremely intelligent members that have taken PaaS and effectively implemented it into their continuous integration and delivery environment giving them strengths that most companies can only imagine to have.

One of those companies is lucky and smart enough to have Jonathan Murray @adamalthus heading up efforts. On his team he also has Dave McCrory @mccrory and Brian McClain @brianmmclain. To boot, they are close to the Cloud Foundry team (and @wattersjames, who cuts a path when there are issues) and keep a solid effort going working with key partners such as @Tier3 (now part of CenturyLink)  and other companies that help bring together one of the most strategically and tactically relevant PaaS deployments to date.

Other PaaS deployments are questionable for various reasons, they’re trying, but they aren’t there. At least not the types of companies and efforts that Barb was looking for. So really, if there is another out there that’s hiding, but wants serious street cred. A boost to hiring serious A grade talent, and to push forward past competitors, please let us know. Let me know, let Barb know and let’s hear about what you’re doing. If a company is hiding their implementation and doesn’t want to be part of the community, then fine, they can stay hidden and not gain the benefit of the community that presses forward beyond them. But I would love to hear from those that I might have missed, that want to push forward, so ping me. Ping Barb, we’ll get word out there and get developers checking out and making sure your company is getting it done! 😉

Second Topic: PaaS on PaaS and Start Docker

PaaS is nice. If your company can get it deployed and use it effectively, the you’re going to push forward fast in many regards. Deployments, savings, code cleanliness, effective separation of concerns and abstraction at a systems level are some of the things you can expect from a good PaaS implementation. Sometimes however, as the senior devs I mentioned pointed out, you give up control and certain levels of abstraction. However almost all senior devs understand that they want the ability to abstract at the levels that PaaS enables. They want to break apart the app cleanly at the system level from the software level. No reason for an app to know where or what a hard drive is doing right? That’s a rhetorical question, onward with the topic…

Docker has entered the market with a BOOM, part of the abstraction level that enables PaaS tooling in the first place. This tool enables a team to jump into the code or to just deploy the tool to abstract at a PaaS level, but to build the elements that they need specifically. The components are able to be brought together in a composite way that provides all the advantages of PaaS, while put together specifically for the problem space that the team is attacking. For environments that don’t make cookie cutter apps that fit perfectly to PaaS tooling as it is, that needs that little bit extra control of the environment, Docker is the perfect tool to bring those pieces together.

So really, is Docker and containerization that new word (from a technically old tech! lolz), that new tech, that’s going to bring PaaS into the mainstream as the standard implementation? Is it going to make PaaS become containerization when we developers talk about it? It could very well be the next big step. It could be that last mile coverage that devs want to push environments into a PaaS Tech ecosystem and make full use of hardware, software and move to the next stage of application development. Could it? Will it?

Personally I’m ready for the next stage of the whole PaaS thing, are you?

Next up on other thought patterns, WTF are people using Oracle for still when mariadb and postgres mean their freedom to innovate, move forward and surpass their competition.

Sorry Database Nerds, Nobody Actually Gives a Shit…

So I’ve been in more than a few conversations about data structures, various academic conversations and other notions about where and how data should be stored. I’ve been on projects and managed projects that involve teams of people determining how to manage data so that other people can just not manage data. They want to focus on business use and not the data mechanisms underneath. The root of everything around databases really boils down to a single thing – how can we store X and retrieve X – nobody actually trying to get business done or change the world is going to dig into the data storage mechanisms if they don’t have to. To summarize,

nobody actually gives a shit…

At least nobody does until the database breaks, or somebody has to be hired to manage or tune queries or something or some other problem comes up. In the ideal world we could just put data into the ether and have it come back when we ask for it. Unfortunately we have to keep caring for where the data is, how it’s stored, the schema (even in schema-less, you still need to know the schema of the data at some point, it’s just another abstraction to push off dealing with the database), how to backup, recover, data gravity, proximity and a host of other concerns. Wouldn’t it be cool if we could just work on our app or business? Wouldn’t it be nice to just, well, focus on things we actually give a shit about?

Managed Data Systems!

The whole *aaS and PaaS World has been pushing to simplify operations to the point that the primary, if not the only concern, is the business itself. This is a pretty big step in many ways, but holds a lot of hope and promise around fixing the data gravity, proximity, management and related concerns. One provider of services that has an interesting start around the NoSQL realm is Orchestrate.io. I’ll have more about them in the future, as I’ll actually be working on hacking on some code against their platform. They’re currently solving a number of the mentioned issues. Which is great, a solid starting point that takes us past the draconian nature of the old approach to NoSQL and Relational Databases in general.

There has been some others, such as Mongo Labs or such, that have created a sort of DBaaS. This however doesn’t fill the gap that Orchestrate.io is filling. So far almost every *aaS database or other solution has merely been a single type of database that a developer can just throw data at in a single kind of way. Not really flexible, and really only abstracting some manual work, but not providing much additional value add around using the actual data. Orchestrate.io is bridging these together with search, replication and other features to provide a platform on which multiple options are available via the API. Key value, geo, time series and others are all coming together for them nicely. Having all the options actually creates a real value add, versus just provide one single way to do one thing.

Intelligent Data Systems?

After checking out and interviewing Orchestrate.io recently I’ve stumbled into a few other ideas. It would be perfect for them to implement or for the open source community to take a stab at. What would happen if the systems storing the data knew where to put things? What would be the case for providing an intelligent indexing policy or architecture at the schema design decision layer, the area where a person usually must intervene? Could it be done?

A decision tier that scans and makes decisions on the data to revamp the way it is stored against a key value, geo, time series or other method. Could it be done in real time? Would it have to go through some type of processing system? The options around implementing something like this are numerous, but this just leaves a lot of space for providing value add around the data to reduce the complexity of this decision making.

Imagine you have key value data, that needs to be associative based on graph principles, that you must store in a highly available system with pertinent real-time data provided based on those graph relations. A decision layer, to create an intelligent data system, could monitor the data and determine the frequent query paths against the data. If the data is growing old it could move data from real-time to archival via the key value. Other decisions could be made to push up data segments into a cache tier or some other mechanism to provide realtime graph connections to client queries. These are all decisions that would need to be made by somebody working on the data, but could be put into a set of rules to allow for re-allocation of the data via automated mechanisms into better storage options. Why keep old data that isn’t queried in the active in memory graph store, push it to the distributed key store. Why keep the graph data on drive when it can be in memory with correlated keys in a key value in memory store, backed by an on drive key value? All valid decisions, all becoming better understood day by day. It’s about time some of this decision process started to be automated.

What are your thoughts? Pro-intelligent data systems or anti-intelligent data systems? Think it’ll work or is it the wrong approach? Maybe the system should approach some other zenith or axiom point to become truly abstracted and transparent?

Only Yahoos Work in an Office!?

Ok, so I think almost everybody has either slammed Marissa Mayer about the new Yahoo non-remote worker policy or said that it’s the medicine they have to swallow. Very few are actually pointing out however, that Yahoo was probably just really bad at managing their remote employees. In the end, I don’t care, that just means there are now going to be more people who are probably great that will be available in a tech market that is happy to hire the talent!

But I do digress, I have something else to talk about that is actually productive. I’m going to kick this off with a short story, that actually inspired me to write this post.

Remote Workers Unite!

I was in the office, a coworking office called NedSpace in downtown Portland with my fellow Bashoians Eric Redmond (@coderoshi) & Chris Tilt. Generally we all work remotely, because everyone at Basho is remote. The entire company, from CEO to HR to Marketing to Engineering, everybody is remote. Basho does a solid job of working like this, it is indeed, a modern Internet enabled software company. However today we were all in the office.

During the day I pulled up Scott Hanselman‘s Blog Entry “Being a Remote Worker Sucks“. I found this on twitter and shortly after reading it, tweeted,

Case Study Coffee
Case Study Coffee

Within a few minutes, lo and behold in the glare of my Apple Cinema Display I see Scott Hanselman walk up behind me! (Isn’t this building secure?!!? Scott’s name is now Hacker Hanselman!) Wow, that doesn’t happen everyday or does it? So Eric & Chris finished up some coding. Chris headed off to return home, where he remotely works from. However Eric, Scott & I headed out for a stroll through the city of Portland to Case Study Coffee. We had a great conversation, discussing all sorts of blog entry ideas, Node.js oddities, duplications between Rail & Node.js & Java & .NET and all sorts of other things. I mean, you probably know how it goes when you have three geeky people going on endlessly about awesome nerdy stuff. Simply put, we covered a lot of topics.

…that’s when I thought…

Offices Are Often The Worse Place to Cross Pollinate Ideas

Not a little bit, but likely the absolute worse places to cross-pollinate ideas. But then I got to thinking a little bit more. Is Yahoo on to something? Is there a need or a reason why people should be in a similar place? I mean, I know for a fact the most rapid learning I ever had was pair programming with other coders. But I’ve done this in an office and outside of the office, at coffee shops and hackathons, on the rooftop of buildings and in dark and dreary bars. I’ve paired with a lot of coders and learned a lot by doing that.

Another question came up, is it really important to be in the office or is it important to be near others you are working with? More of that thinking and remembering things and more experiences popped into my mind. Whew, this was becoming a serious thinking session. I’d also had a great experience working remotely and learning at practically the same rate with friends. We were all working on an open source project. We asked questions in general chat on IRC or other places, and got instant feedback and help when we needed it. We’d put ideas into chat and discuss them readily and sometimes excessively. We weren’t anywhere near each other, specifically we were about 1400+ miles from each other in different time zones. But it worked and it worked damn well!

My correlations in trying to figure out, should employees be in office or out of office could go on. As Eric said when we all returned form the coffee shop, “correlations do not show causation, but they sure as hell imply it“. Well, I didn’t want to just imply onsite or remote work is better I wanted to know what really works or doesn’t. More thinking ensued and then…

Freedom Punched Me In The Face

Then it hit me. Geographic location doesn’t make any difference. The difference, which also makes Yahoo’s demand for no more remote working, is again the freedom of the individuals involved. The freedom to work where we are needed with who we ought to and need to and when we are most efficient and capable of performing the work best. The key is this freedom is granted, and that driven self organizing individuals make use of this freedom. It may be that one day we might end up in the office while another day we end up in a park, at home or in some coffee shop.

So forget remote working or in office working. These things aren’t correlated to someone being productive or not, the core reasons someone is productive is the ability that they have the freedom to be productive in the way that best works for them and for the company they’re providing services for. The most important thing is being able to give freedom to those doing the work to be productive. Remote or not is pure distraction and in turn is bullshit.

Don’t get distracted by the remote or onsite worker debate, figure out the best ways to work with your employees based on individual freedom. You’ll have far more productive individuals than any existing hierarchical corporate structure nonsense.

ETLs and APIs – A Thought Stream on the Matter, Are Things Really Changing That Much?

Often the tendency has been, and largely still is in Enterprises, to build things really large. Doing big design up front (BDUF) all the way to creating massive JavaScript libraries for generating JavaScript from non-JavaScript langauges, leading to a huge case of analysis paralysis and other such keywords that all point to the mythic man month or software death march. In the end, building big is building to fail – in a non-learning, non-useful, big bank, financial collapse type of failure. So mumbo jumbo aside, what am I saying?

I recently read the article by Anant Jhingran over at apigee titled “From ETL to API A Changed Landscape for Enterprise Data Integration“. In the article Anant points out a number of things around this movement to APIs versus ETL efforts in leading enterprises. I couldn’t help but notice this is a recurring theme in software development and with humans in general.

Observation

With Governments: Central planning through attempting to dictate order (i.e. Soviet Union) will eventually fail  for a less dictatorial plan around keeping things simple and organizing around communities to plan large efforts.

Translation to Tech: Having mainframe/server that dictates order will eventually fail for a less controlled Internet of systems that maintain simplicity and organize around communities of people to create large efforts.

Translation to Software: Building homogenous massive systems of record that dictate order will eventually fail for less controlled service orientation that can maintain their own system of record around departmental domains of people to create and operate large efforts, like enterprises.

Of course, the concern I have is, we humans tend to do things in a cyclic nature, as with Governments we move toward freedom and liberty, then the other direction, then back again. Big control to little control to big control again.

Summary

I see the point in the article, bringing the ETL massiveness under control of the smaller services, but in the end what we all need to do is to keep things in perspective. The extraction, transformation and loading of ETL still needs to occur along with the usage of application programmer interfaces ala the APIs. So where does this really get us, this acknowledged shift? It really just brings into focus a desire to simplify and bring things into a manageable state in the Enterprise. It makes sense that the leading enterprises are doing this, simply because they’ve reached that maturity level. Of course there will still be thousands upon thousands that haven’t reached this maturity point and will have to go through the pain of large scale centrally managed and planned ETL systems.

In the end, we’ll always have to return to the simple things to get true understanding.

Doing a Video Show, Killing Podcasts, Lighting Fires, Code, More Code, New Technology and Making Things Happen!

Video Production is starting soon on a new hard core coder & tech video show. Done on the nitty gritty. It’s going to be about purely tech, code, more code, testing, coding, entrepreneurship in technology (not in general) and more of the hard core, nitty gritty, total hands down low down on the technology sector and technology scene. We’ll be diving into everything from enterprise technology to startup technology, who’s innovating and who’s stagnating, who’s kicking ass and who is enjoying the ride.

What I’d love from you, dear reader, is help with this question. What kind of content would you like?