(c)iStock.com/Enkiinmu

Nitrous.io, a Singapore and San Francisco-based cloud integrated development environment (IDE) provider, has announced it is to shut down its development platform and cloud IDE on November 14, with customers given until that date before their data is deleted.

The company has stopped new signups, and said that payments made after October 16 will be refunded in full, as well as promising that subscriptions to any Nitrous email list will expire at the end of this month.

While two weeks is a less than ideal timeframe to sort out new data, the company said in a blog post confirming the shutdown that customers who have an active workstation will be able to easily download a backup of their data through an email link.

The company added that a self-hosted and open source version of the Nitrous IDE, called Nitrous Solo – which will allow users to host their own instances on other cloud providers – will be rolled out “in the coming weeks.”

According to Crunchbase, Nitrous.io, previously known at Action.io, received a total of $7.65 million in funding across two rounds; one of $1m in seed funding in April 2013, alongside $6.65m of series A in March 2014 led by Bessemer Venture Partners. The company launched a professional version of its development platform in April last year, claiming at the time that more than 200,000 people had registered and built apps using the original free version of Nitrous.

You can read the full blog post here.

(c)iStock.com/Erik Khalitov

The vast majority of companies who are moving to cloud applications also have a significant current investment in on-premise operational applications and on-premise capabilities around data warehousing, business intelligence and analytics. This means that most of them will be working with a hybrid cloud/on-premise data management environment for the foreseeable future.

Moving at ‘cloud speed’, and setting up a new application in a matter of hours, is a big advantage in terms of business agility, but one cost is that managing data becomes more complicated.

It seems that more often than not, a hybrid architecture isn’t planned – it just happens. The ‘typical’ use-case pattern starts with organisations integrating a cloud application, perhaps for CRM or HR, then, they add cloud database before finally adding a cloud data warehouse and/or analytics capability.

A lot of the time it’s the business that drives this pattern in an effort to solve a particular problem. Most frequently, IT is hugely involved in the effort, but the cloud analytics decision is made by the business side. As a result, IT inherits significant new data management complexity.

Implementing data governance

It can be difficult to retrofit governance into existing systems. Often, the focus is on the initial data migration to the new operational application or analytics, where a simple bulk data loader is employed in the interest of speed and agility. This has several downsides:

• There is no metadata. Using a data integration tool with metadata support, instead of a bulk loader, will give you an end-to-end view of your data lineage throughout your environment. This will be critical as the complexity grows and you need to make changes, quickly and without errors
• The opportunity to do a data clean-up while moving the data is lost, and you risk populating a new application with ‘bad data’
• You miss the opportunity to think about ongoing data security and data governance on a broader scale

Once the new applications have gone live, focus shifts to ensuring data consistency. Moving between cloud and on-premise systems and cloud-to-cloud brings new challenges, and leave fewer resources dedicated to overall data management.

If you don’t want to slow down the business initiatives that are driving the new applications, but still want to prevent that data complexity or chaos, it will pay to have a data management architecture and best practices in place before-hand.

The hybrid data management checklist

Data management in a large organisation is challenging. But this gets even more complex when it’s hybrid. The key is to plan ahead so that you’re not a roadblock to the business. Key considerations for a successful programme should question:

• Does your software provider offer out-of-the-box, high-performance connectivity to all of the on-premise and cloud sources?
• Does your software provider have compatibility across their on-premise and cloud data integration capabilities including shared skills, shared code (mappings), shared management tools?
• Do they support multiple integration patterns: batch, real-time, API integration?
• Can they smoothly enable you to grow your data management capabilities as you need them covering data quality, data governance, master data management, metadata management, security, B2B?
• Do they support wizards and template-drive development for ‘citizen integrators’?
• Do they have metadata management tools for data lineage and business meaning and context. This is critical for reducing errors, enabling self-service, and speeding changes to the environment
• Do you have a central point of operational management for data?
• Can you manage quality and governance of data across a hybrid environment?

At the end of the day, the business challenge is to deliver value faster than the competition. The IT challenge comes with meeting the speed and quality requirements of the business while enabling them to accelerate their business agility. It can be done, but it takes careful planning and a good, forward-looking data management architecture.

(c)iStock.com/JurgaR

Another quarter, another period of dominance for Amazon Web Services (AWS) in public cloud IaaS – according to the latest analysis from Synergy Research.

The figures tell a similar story from previous quarters; the market leaders are growing faster than the rest of the market, but while Microsoft and Google are growing faster than AWS, the Seattle-based giant still holds 45% of the worldwide public IaaS space, dwarfing Microsoft, Google, and IBM’s shares put together.

When it comes to public platform as a service (PaaS), AWS is still the market leader, although the three nearest challengers – Salesforce, Microsoft and IBM – hold slightly more share combined this time. For managed private cloud, however, IBM leads the way with almost 20% global market share, ahead of AWS, Rackspace, and NTT.

The latest figures may show more than ever an entrenched space with the winners and runners up decided.

Yet Synergy argues that in some cases, second tier companies are attempting to buck the trend; Chinese giant Alibaba, in IaaS, and Oracle in PaaS.

Speaking to this publication in July, when Oracle confirmed it was to acquire cloud ERP software provider NetSuite for $9.3 billion, Synergy chief analyst John Dinsdale noted that while the deal would not ‘directly’ help Oracle in the PaaS market, it distinctly remained a top 10 player.

Here, though, the findings are clear. “Amazon, Microsoft and Google continue to invest huge amounts in their hyperscale data centre infrastructure, and all three have recently expanded their data centre footprints and also announced plans to open up more geographic regions in the coming months,” said Dinsdale. “This scale is the prime reason why they are able to gain market share and pressure smaller players into consolidation or refocusing their cloud activities.”

AWS announced in September plans to launch a data centre in Paris, while in the same month IBM sealed the deal to open up a centre in Norway, citing continued Nordic cloud demand.

(c)iStock.com/TERADAT SANTIVIVUT

In the world of security, monitoring and analytics solutions for IaaS cloud, there’s a lot of discussion and debate about agent-based vs. agentless service architectures. Your choice of agentless vs. agent-based cloud security can have a big impact on the efficiency of your day-to-day operations for security and compliance as well as your ability to protect your cloud environment in the future. It’s important to understand what the difference is, and be fully aware of the tradeoffs involved in this decision.

So what’s the difference?

Agent-based and agentless services basically differ from each other in how they collect information and provide control across the entities in your cloud environment (network/security groups, server instances, load balancers, database services, etc.). With an agent-based workload security product, you install a small software agent in each of your server instances. The agent is responsible for collecting relevant information from the server it is installed on, sending the information back to a central control system, and giving you the ability to control security at an instance/virtual machine level. For example, agent-based security products gather information about host firewall setup and network traffic flowing between servers, and provide file integrity monitoring (FIM) and the ability to configure the firewall on each host. 

Figure 1: Data aggregation and control with an agent-based approach to cloud security

Agentless services, on the other hand, talk directly to the underlying cloud platform (e.g., AWS, Azure) through the service provider’s API to get information about instances, services and the network, and control security. Because the agentless service talks directly to the platform, no modifications are required in the resources that are part of your environment. Because of this, agentless services, also called cloud-native or API-based services, are completely transparent to the applications and workloads.

Figure 2: Data aggregation and control with an agentless approach

Why it matters

The first workload security platforms for public cloud environments were agent-based. This was in part because the security mechanisms exposed by cloud service providers were still evolving and weren’t as feature-rich in the early years as they are today. Agent-based tools also gave businesses that migrated workloads to the public cloud a way to bring tools that were developed for datacenter environments (and which they were familiar with) into public cloud environments. This made the transition to the public cloud easier for some of them.

But agent-based solutions designed for more static and predictable datacenter environments are a poor fit for the dynamic needs of a public cloud environment. Let’s look at five reasons why.

1. Operational Overhead of Agent Management: In agent-based solutions, you are responsible for installing agents on every instance in your cloud environment, keeping the agent current and up-to-date, and troubleshooting any connectivity issues. This is of course something that has been commonplace in the world of enterprise IT. Customers of endpoint security solutions such as Sophos and antivirus products such as Intel McAfee are used to dealing with agents in Windows and Linux hosts.

However, in cloud environments where you have hundreds or thousands of instances or virtual machines across dozens of VPCs around the world with hundreds of accounts accessing them, and you have instances being added and deleted from your environment frequently, the complexity of managing even something as simple as agents becomes a significant burden. Agent management opens up another small window of vulnerability in a cloud environment. Who can guarantee that an agent is installed on a newly launched rouge instance? In environments with multiple business units and stakeholders with their own configuration management systems and base images, ensuring that an agent is installed in each instance is particularly hard.

2. No Place to Install Agents in Function-as-a-Service (FaaS) and Built-in services: Even as late as five years ago, AWS for most enterprises was just three or four services, namely EC2, S3 and EBS. You could install agents in EC2 instances and fully protect your environment. 

But as of 2016, public cloud has exploded in terms of services offered, now looks more like this:

Figure 4: Broad range of services on AWS today

Many businesses now actively use the built-in database services (DynamoDB, RDS), load balancers (ELB) and big data services (EMR, ElasticSearch). FaaS offerings such as AWS Lambda (aka serverless computing) are also becoming popular. These services either don’t let you install agents in them, or have nowhere to put an agent (where does the agent go in a Lambda function?). Agent-based solutions completely fail to monitor or protect these services. You may not be using these services actively today, but do you want your cloud security solution limiting what you can monitor and protect in the future?

3. No Awareness of Cloud-Native Services: Not only do agent-based security products fail to protect cloud-native services such as ELB and RDS, but they do not even allow these services to be modeled in instance security policies. For example, there is no way to specify in a security policy that an instance can get incoming connections only from an ELB or can send outbound traffic only to RDS. You have to resort to an overly permissive “open to all” approach because of these limitations.

4. Cloud-native security with cloud-agnostic policy automation wins: Managing security and compliance in a cloud-agnostic way is important not only for hybrid cloud scenarios but also for multi-cloud deployments where you may have workloads running on Azure and AWS and don’t want to be tied exclusively to one particular platform. You can achieve cloud-agnostic security management without having to install and manage agents. Cloud security platforms allow you to manage the security posture of multiple public cloud environments by specifying policies and rules (the “what” of cloud security) in a cloud-agnostic way while using the native capabilities of each cloud to implement and enforce the security policies (the “how”). You get the best of both worlds, because you are able to specify security policies once across multiple clouds, and then use the powerful controls provided by each cloud to implement them.

Figure 5: Combining cloud-native implementation with cloud-agnostic policies

5. Unnecessary tax on your AWS environment with agent-based approach: With agent-based solutions, not only do you have agents running in each instance and taking a bite out of CPU utilization, you also have these agents talking to a service controller and consuming bandwidth in your cloud environment. The overhead is, of course very small, but nevertheless it’s still a tax that you are paying on your cloud bill. In an agentless solution, the security platform talks directly to AWS through the cloud’s control plane API, without impacting performance or resource utilization in your cloud environment. 

A recent report by Praetorian, a cybersecurity company headquartered in Austin, TX, focused on threats that resulted in data compromise or access to sensitive information. Based on a review of 100 separate internal penetration test engagements the study identified the five most prevalent threats to corporate data. The amazing thing about these weaknesses is that the top four are all based on utilizing stolen credentials and the last one helps an attacker be more effective in using those stolen credentials. In other words, the enemy is right there in the mirror! The study spanned 75 unique organizations and only focused on security weaknesses that were used to obtain a full network compromise.

read more

Virgil consists of an open-source encryption library, which implements Cryptographic Message Syntax (CMS) and Elliptic Curve Integrated Encryption Scheme (ECIES) (including RSA schema), a Key Management API, and a cloud-based Key Management Service (Virgil Keys). The Virgil Keys Service consists of a public key service and a private key escrow service. 


read more