Head in the Clouds: SaaS, PaaS, and Cloud Strategy


July 23, 2015  8:03 AM

Is Shadow IT always bad?

Joel Shore Profile: Joel Shore
Mobile Application Development, Rapid Application Development, Shadow IT

We’ve all seen it. That chief marketing officer wants a new report or a redesigned user experience on the company’s mobile app. The guy is already fed up with an IT department and CIO he sees as everything from active obstructionists to clueless, unresponsive ne’er do wells.

IT isn’t interested, doesn’t have the people or budget, has other more-pressing projects on the docket, or may simply doesn’t get what the marketing team is trying to accomplish. What happens next is that the department decides to go around IT and sign up for some software-as-a-service subscription or, increasingly, use a no-code drag-and-drop tool to build mobile apps that connect to company data through an assortment of APIs. After all, the point of many APIs is to simplify access and integration. The result: Shadow IT.

I’ve heard it argued that Shadow IT can’t harm corporate intellectual assets (data) if the apps built are read-only, perhaps for generating sales or inventory reports. I’m not buying that argument, though it depends how you define harm. While prohibiting write access does protect digital assets against dastardly destruction, deliberate deletion, or worse, evil editing, a read-only app still puts the data out in the wild, where you have no control over who can see it. That doesn’t damage the data, but it certainly could harm the business.

As for these no-code tools, the selection abounds. Industry analysts are even looking at them as a good way to accomplish tasks that move the business forward without straining developer resources that are already stretched thin.

Shadow IT is inevitable. To make it work better for everyone, I’d like to see the marketing department be less surreptitious about it. Go to IT and say, “We’re going to do this and we wanted you to know before we start.” Not only is that good corporate citizenship, but it increases the likelihood that IT will take at least a cursory look at the tools and project intent to ensure that security is up to snuff and regulatory mandates (HIPAA, for example) aren’t smashed to smithereens.

As a developer or CIO, what’s your opinion of the trend toward departmental no-code app development? Everyone I speak with has strong feelings. We’d like to hear yours.

July 14, 2015  9:10 AM

Get rich selling in app stores? Not so fast.

Joel Shore Profile: Joel Shore
App store, apps, Mobile applications

Working in a corporate IT department or for a software house as an application developer has its benefits, namely a regular paycheck. But, you probably want more. You dream about selling your own apps through the Apple App Store, Google Play, or maybe even the Windows Store. Good luck.

Microsoft’s Nick Landry, Sr. is a technical evangelist and all-around cheerleader for all things mobile on all platforms. (He’s a mobile guy, not a Windows guy.) Landry especially loves developers who have big ideas for small apps. Write an app with a goal of selling it in an app store? Absolutely. Go for it, he says with a big smile and wide eyes. But, don’t expect to get rich doing it. And, definitely don’t quit your day job thinking you’ll generate enough income to live comfortably. Those who strike it rich selling apps are like the people featured in those late-night weight-loss infomercials — their results are not typical. “It’s an extremely competitive world where you have literally millions of applications out there,” Landry says. “It’s very hard to get discovered; it’s not like ‘if you build it they will come.'” He’s right; your app will literally contain fields of dreams.

Whatever the idea you conjure up for an app, it’s likely already been done hundreds or thousands of times. After your app is finished and you submit it, the scrutiny begins. In its App Store Review Guidelines, Apple itself has a lot to say, including “If your App doesn’t do something useful … or if your app is plain creepy, it may not be accepted,” and ” we will reject Apps for any content or behavior that we believe is over the line.” The guidelines includes lengthy sections covering everything from metadata to push notifications, user interfaces to trademarks, personal attacks to violence, objectionable content, and a whole lot more.

Get past all the obstacles and watch the dough roll in? Not so fast. Landry says you have to do a “ton” of marketing and promotion to even get noticed. Marketing, though, generally doesn’t come naturally to techie types. That’s why Steve Wozniak had Steve Jobs, why Bill Gates had Steve Ballmer.

No less an authority than Gartner weighed in on the subject. In a 2014 report, Gartner said less than 0.01% of consumer mobile apps will be considered a financial success by their developers through 2018. In the words of Ken Dulaney, vice president and distinguished analyst at Gartner, “There are so many applications that are free and that will never directly generate revenue. Gartner is forecasting that, by 2017, 94.5 percent of downloads will be for free apps.”

Of course, there will always be the one app that just happens to go viral on its own, but it’s not the sort of thing that one can plan. “It’s something you can hope for,” Landry says, “but, you cannot build a strategy on hope.” Talk about a dose of reality.

“Discoverability is a real challenge. If your app is not among the top 50 in its category, the chances are it will never be downloaded,” Landry says. That’s certainly a sobering dose of reality. According to Statista, as of May 20, there were 1.5 million apps in Google Play, 1.4 million in the Apple App Store, 360,000 in the Amazon Appstore (who knew?), and 340,000 in the Windows Phone Store.

He adds that 17% of independent developers generate no revenue at all from their apps while another 18% make less than $100 a month. In other words, if you’re in it for the glory and experience, have at it. Revenue streams, not so much.

But, you still have your dream. Go for it. Landry isn’t trying to talk you out of anything. He is, after all, a mobile app evangelist. He simply wants to be sure you understand the rules of the road. Write that app. Go through the testing and vetting process. Watch it go live then impress your friends. And us. We’d like to hear from you. Share your app store development challenges and successes.


July 8, 2015  7:13 PM

Computer glitch? Admit it, there’s no such thing

Joel Shore Profile: Joel Shore
Application development, Error handling, Quality assurance, Software QA

Update on July 9: Reuters is reporting that yesterday’s New York Stock Exchange computer outage was caused by a software update. According to Reuters, a spokeswoman for the NYSE said the root cause was a “configuration issue.”


Original blog post on July 8: Today was a rough one for enterprise IT. The New York Stock Exchange came to a screeching halt. United Airlines was directed by the FAA to halt all flights systemwide. And the Wall Street Journal’s website was down for much of the day. Suffice it to say that Wednesday, July 8, 2015 will not soon be forgotten.

United’s woes were blamed on a bad router. We’ll save the discussion of hardware and communications redundancy for another day. As of this writing, no reason for the Journal’s outage had been made public.

And then there is the NYSE. Turn on any news program or read about it online and you’ll learn what happened: a computer glitch. I can’t think of anything more annoying. Or more wrong. Let’s be very clear about this one thing: There is no such thing as a computer glitch.

Systems go down for only three reasons. First is hardware failure. We all understand that. Routers fail, servers fail, a drive crashes, the power goes out, squirrels chew through power or communications lines, lightning strikes, or something else. Redundancy should reduce the vast majority of incidents to a momentary blip during a cutover.

Second is sabotage, hacking, denial-of-service attacks, or some other deliberate action. No further explanation needed.

Third is that glitch. The problem is that glitches don’t exist. They never have. And the general news media doesn’t understand that. Computers or devices are very stupid, they can do only what they are instructed to do. You and I have a word for those instructions — software. If the software is poorly written, fails to test for all conditions, has security holes, contains faulty logic, or was installed or configured incorrectly, the program and whatever hardware it’s running on may behave in an unexpected manner or produce undesirable results. I don’t want to say “wrong” or “erroneous” results, because the software is functioning exactly as written.

It doesn’t have to be servers or networks. My DLSR cameras have been known occasionally to perform in a way that defies explanation. But, then along comes a firmware update, and all is well. Until the next time.

What’s your take on glitches? Share your opinion; we’d like to hear from you.

 


July 8, 2015  9:16 AM

Choose integration tools with care

Joel Shore Profile: Joel Shore
Application integration, Cloud integration, Data integration, Development tools

No two IT infrastructures are alike. We all know it’s true. Tiny differences in applications, configuration, or patch status pretty much guarantee that no two “identical” servers can ever be exactly alike. Similarly, no two integration projects are alike. Choosing the right tools for integration projects varies widely, even for different corporations that run the same software. Choose carefully, says Forrester principal analyst Henry Peyret.

“The integration landscape is changing under cloud, mobile, and IoT,” he says. That means new and continually changing requirements inevitably lead to integration scenario complexities. What was true yesterday might be just a little bit different today. You already know that if you’re rolling out weekly updates to a mobile app.

“This complexifying integration landscape is challenging the existing integration strategic investments like ESB (enterprise service bus), EAI (enterprice application integration), and ETL (extract, transform, and load).” Even though “complexifying” wasn’t in my spell checker, what Peyret says is crystal clear.

It’s not just cloud, mobile, and IoT. It’s about which specific applications you’re trying to integrate, whether they reside on-premises or in the cloud, and which data sets they need to access and share. These are all complicating — or complexifying — factors. Add security and access considerations to the mix, along with data sovereignty requirements, governmental mandates, and corporate governance rules, and you can get in the middle of a serious challenge very quickly.

So what does this mean for integration tools makers? A lot. It means the tools have to adapt nearly as fast as your company does to ever-changing market conditions. Says Peyret, “The tooling market is facing multiple convergence between cloud and on-premises (creating hybrid integration), convergence of data, and event-based interfaces, such as batch and event in a single integration solution.”

The first consequence is that there are multiple new offerings available, but not all are adapted to support what Forrester characterizes as dynamic Integration. What do you need to do? “Companies should plan for tactical choices today which have the potential to become strategic investments, but they should not expect to get one single solution for all their integration scenarios,” says Peyret.

And there it is. No one tool is likely to meet all of your application- and data-integration requirements.

Have you found this to be true? Which tools did you choose and what consideration drove you to that decision? Share your thoughts; we’d like to hear from you.


June 26, 2015  12:20 PM

Red Hat’s new OpenShift Dedicated PaaS enters beta phase

Joel Shore Profile: Joel Shore
OpenShift, PaaS

At the Red Hat Summit, in addition to announcing that its OpenShift Enterprise 3 private PaaS is now in wide release, Red Hat took the wraps off of a beta version of OpenShift Dedicated, a totally new public cloud service based on the OpenShift 3 platform.

There’s no announced target date for release, but Red Hat is currently accepting online applications to participate in the tech preview.

The Red Hat team said that Dedicated uses the same code base as OpenShift Enterprise 3. The main difference is that OpenShift Dedicated is hosted on the public cloud and managed by Red Hat. In comparison, OpenShift Enterprise 3 subscriptions entitles businesses to host and manage the software in the infrastructure of their choice.

This service builds on the OpenShift Online public PaaS platform, but adds the ability for businesses to  build, launch, and host applications in the public cloud by offering enterprises a dedicated instance of OpenShift that’s managed by the OpenShift operations team. As the Red Hat folks put it, OpenShift Dedicated “brings the power and flexibility of OpenShift 3 to the managed public cloud.” It’s hosted on AWS.


June 26, 2015  12:01 PM

Red Hat’s OpenShift Enterprise 3 PaaS gets a formal launch

Joel Shore Profile: Joel Shore
OpenShift, PaaS, Red Hat, Web Application devlopment

Stand in any hallway during the Red Hat Summit in Boston this week, and you were likely to hear the c-word. Containers. And the d-word, too. Docker. Those two words seemed to get people more revved up than the energy drinks I saw being consumed everywhere, too. (The p-word, Python, wasn’t that far behind.) None of this is lost on Red Hat, of course. The company responded with its big announcement of general availability for OpenShift Enterprise 3, its enterprise-ready Web-scale container private PaaS. It’s based on Docker format Linux containers, Kubernetes orchestration, and Red Hat Enterprise Linux 7, providing full support from the operating system to application runtimes. (Version 7.2 of Enterprise Linux is not too far away.)

Of the three flavors Red Hat offers for OpenShift, this is the one that changes the least and is likely the logical choice for corporate cloud app development. OpenShift Origin, the free community PaaS is where changes and updates first get posted, and that can be dozens over the course of a month. Though it’s a great way to get started, it’s ultimately not where businesses will want to be. In the middle is OpenShift Online, operated and supported by Red Hat in the public cloud.

So what is Red Hat doing in OpenShift Enterprise 3? It delivers a container-based application platform based on Docker and powered by Red Hat Enterprise Linux. The idea is to provide a secure, efficient, and portable way to develop, deploy and run application services. OpenShift users also get access to a pretty big ecosystem of vetted, secure packaged application components, thanks to Red Hat’s Container Certification Program.

OpenShift Enterprise 3 includes the Kubernetes the open source, container orchestration and management engine developed with Google. What’s interesting is that with Red Hat as a contributor to both the Docker and Kubernetes open source projects, it’s eating its own dog food.

After sitting through more than a half-dozen one-hour sessions over two days, OpenShift was right at the top of those hallway conversations.

Shawn Zamacheck, a research developer at the Wharton School in Philadelphia is a fan, and a user. He uses OpenShift for creating research surveys. He looked at competing PaaS offerings, including Heroku. AWS didn’t have anything suitable a couple of years ago when he was looking around. He settled on Red Hat mainly because it was stable and supported a wide swatch of technologies.

 


June 26, 2015  8:49 AM

Dell, Red Hat team for new PaaS offering

Joel Shore Profile: Joel Shore
Cloud Services, Dell, PaaS, Red Hat

At the Red Summit this week in Boston, I had a chance to do an extended sit-down interview with Jim Ganthier, Dell’s vice president and general manager of engineered solutions and cloud. For a guy who works for what we all picture as primarily a hardware company, he had very little to say about hardware. Very little. These days, it’s about cloud, it’s about services, it’s about open source, and it’s definitely about partnerships with Red Hat. In the spotlight on this morning was Red Hat’s OpenShift PaaS.

For enterprise customers seeking a services-based cloud solution, Dell’s services organization has been working on a new solution for public cloud. It’s built on a Dell-branded OpenShift platform and aims to deliver deployment, migration and management of the operating system and applications via an OpenShift Online platform. Red Hat is not just a bystander to this; the company will manage this all-new PaaS environment. Ganthier told me this is the first Dell-branded PaaS platform designed specifically for Red Hat.

In an interesting side move, Dell Services is also joining the Red Hat Global System Integrator Program. That’s a program designed, to use Dell’s wording, “for partners that demonstrate leadership, unique capabilities and commercial relationships with global enterprise customers.”

It turns out that Red Hat and Dell go back a long way together: Dell was the first computer maker to pre-install Red Hat Linux.

Ganthier had plenty to say on other topics, too. He’s very hot on the idea of “cloud repatriation.” We’ll examine that in another blog post.

 


June 22, 2015  10:32 AM

HP keeps the tools coming; this time for continuous testing

Joel Shore Profile: Joel Shore
Automated Testing, Continuous delivery, Continuous development, Quality assurance

It’s becoming apparent that 2015 is a year in which we’re being showered with cloud and mobile development tools from all sides. It seems new tools are being announced weekly. One of the companies that has become quite aggressive is HP. That’s a really good thing to see. I hadn’t been sure what HP wanted to be, but the company is clearly going back to its roots as a supporter of developers and development technology.

Following other tools announcements earlier this year, the company in June launched HP LeanFT,  a new functional test automation solution. It allows software developers and testers to leverage continuous testing and continuous delivery. This means you can rapidly build, test, and deliver secure applications. This is exactly the sort of thing that is increasingly important as organizations strive to achieve faster time to market without sacrificing quality. While “fail fast and fix” does have its devotees and may be fine for non-critical consumer-oriented entertainment apps, it’s not going to embraced by developers of corporate and commercial apps that have no room for error.

Someone who had hands-on with LeanFT during its development is Jonathon Wright, director of testing and quality assurance at Hitachi. “With Agile and DevOps, there is a strong focus on continuous testing and continuous delivery. This means there is more emphasis on testing much earlier in the software development lifecycle,” he said.  He’s certainly right about the testing aspect. “HP LeanFT is built for continuous integration and continuous testing to help software developers and testers rapidly build, test, and deliver secure, high-quality applications.”

Well, sure, there’s a little marketing-speak in that last sentence, but Wright is corroborating the theme I’m hearing more often: continuous testing and continuous delivery rules the day. HP designed this to fit into existing ecosystems (such as Microsoft TFS, GIT, and Subversion) and frameworks that support test driven and behavior driven development.

To simplify testing, LeanFT provides project templates for standard unit-testing frameworks, including NUnit, MSTest and Junit. The idea is to improve collaboration and alignment between software developers and test automation engineers. And let’s face it, we’ve probably all seen situations where that collaboration can use a little boost. What HP is aiming for is a reduction in the time needed to test applications. That, in turn, should help developers to predict and identify defects earlier in the software development lifecycle.

HP LeanFT is currently scheduled for availability in July. HP Unified Functional Testing 12.5 and HP Business Process Testing 12.5 will also be available in July. It will be interesting to see what else HP has up its sleeve.


June 17, 2015  9:27 AM

Is mobile software really this bad?

Joel Shore Profile: Joel Shore
Mobile Application Development, Program Debugging

Every day, I check my iPhone to see which apps have been updated. Think of it as the latest fad in armchair spectator sports. What I see only reinforces my belief that mobile apps may look pretty, but are often scary bad under the hood.

One app’s “What’s New” section reports “corrected issue with removing previous purchase,” “improved reliability,” and “corrected other issues.” Another app reports “we may have exiled some bugs.” From the Google app, we get “bug fixes and performance improvements.” Panera Bread’s app tells me “various bug fixes.” The Starbuck’s app notes “this release contains bug fixes and enhancements throughout the app.” Shazam’s 8.6.1 update tells me “We know, we broke a few things in 8.6. For those of you who’ve been getting crashes on startup, update now and things should be back to normal.” The Walgreens app, version 5.2.2, lists specific bug fixes. Evernote’s June 12 version 7.7.7 update reports “numerous bug fixes and improvements.” Even the app that I use to measure connection speed says on its latest update, “this is primarily a bug fix release.” Was it reporting erroneous speeds?

The Facebook app notes that it delivers an update every two weeks and that “every update … includes improvements for speed and reliability.” You’ve got to wonder how much faster and more stable it can get. Or, if you’re a professional skeptic like me, you wonder how miserably slow and undependable it must have been 26 updates, or a year ago.

Apps that are downright ugly or feature unfriendly, convoluted user navigation are a different matter. We’ll save that for another blog post.

Some apps are indeed problematic enough that they merit being banished from my phone. There are apps that never got past their startup screens without crashing. There are apps there were so slow as to be incredibly annoying. And there is one app that insists I’m someone else. That’s especially disconcerting.

So what’s going on? Are mobile apps as bad as these messages suggest? Well, yes and no, according to people I talked to during the recent Cloud Computing Expo in New York. We all understand that software is never really finished. On my desktop PC, Microsoft’s “Patch Tuesday” provided updates for Windows XP for 13 years, until support finally ended in 2014. The same, apparently, is true for mobile apps, only that updates come more frequently. I’ve seen updates on one day followed by another on the very next day to repair something the first update simply broke.

Is this due to bad app design? Incomplete specs? Poor coding? Inadequate testing? A rush to get apps published? A conscious strategic effort to “fail fast” and fix? Or something else?

If you’re an app designer, developer writing code, or QA tester, you already have pretty strong feelings about this. Let’s hear them.


June 14, 2015  10:35 PM

Incorporating security into an app starts on day one

Joel Shore Profile: Joel Shore
Application development, Application security, cloud encryption, Data Encryption, FIPS, Mobile Application Development, Security compliance

I won a football at the New York Cloud Computing Expo in a session about encryption. Ask a meaty question and the speaker just might toss you a prize. My question was simple: If the only way to protect all the data is to encrypt all the data (except that which is already public), aren’t edge devices like tablets and smartphones going to suffer a potentially significant performance penalty since everything will need to be unencrypted before it can be used and then re-encrypted for transmission?

Well, yes, of course, said Ray Potter, CEO of SafeLogic, as he heaved a small toy inflatable red football emblazoned with the SafeLogic logo my way. Encrypt. Just get over it. Just do it. Don’t encrypt and you’ve got a good chance of becoming front page news. Right, U.S. Government? Right, Sony? And while you’ve got encryption on your mind, understand its three pillars: confidentiality, integrity, and availability.

Confidentiality, the idea that information should not be disclosed to people who shouldn’t have it. This is the idea of encrypting data and making it unreadable to attackers. Integrity, as Potter puts it is “making sure that data isn’t mucked with in transit.” A use case might be financial transfers where you need to make sure that account numbers and amounts are not compromised.

Third is availability, which might not initially appear to be related to security. But, it is. “We see a lot of distributed denial-of-service attacks that take down a server or an entire site,” Potter says. Think about Amazon going down. That’s a major loss of both revenue and goodwill. Yes, availability is security.

Regarding encryption, Potter says it fits everywhere, even on your spiffy new smartwatch. What each business needs to undertake is a risk-management plan, figuring out where data lies in the system, classifying data in terms of its sensitivity or the assets it protects, and then assigning weighted metrics. What’s typically revealed is that encryption, which was once done at the device level, now needs to be everywhere. What it boils down to is that data needs to be encrypted both in transit and at rest. Otherwise, you could be the next Sony Pictures or Anthem Health Insurance.

When it comes to encryption standards, there’s really only one that matters, and that is FIPS 140-2. The Federal Information Processing Standard (FIPS) Publication 140-2 is a cryptographic standard maintained by the Computer Security Division of the U.S. National Institute for Standards and Technology. It encompasses four distinct security levels, but for most commercial (read that as non-governmental) applications, level one is usually sufficient.

Even though FIPS 140-2 is the standard you need to implement when building your applications, usually followed by compliance verification and certification testing for certain environments (governmental and healthcare, for example), there is one gaping hole. The current version, enacted on Nov. 15, 2001, predates mobility — the existence of tablets by a decade and the mainstream advent of mobile phones by many years.

If you’re a business that’s signing up for anything-as-a-service, part of your due diligence is a demand to see the provider’s FIPS compliance certificate. And you also need to know on what exact platforms compliance has been tested — and which platforms haven’t been tested.

 


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: