As more and more organizations become familiar with the cloud, they are moving towards buying software as a services (SaaS) based on actual usage. In fact, it is predicted that SaaS will become the dominant software consumption model by 2018. According to Gartner, as this occurs the steep decline in maintenance fees will translate into a total revenue loss of up to 40% for Independent Software Vendors (ISVs). This means that ISV’s priorities are shifting, leading to changes in their current operating models.
Having been in the software industry for many years, I have seen first-hand what it means to transform from a traditional license and maintenance fee model to a subscription based SaaS. Through numerous discussions with ISVs with regard to transforming their business, what I’ve found is that while there is no single right approach, there a few common themes that always arise. What follow are 7 strategic considerations to keep in mind.
1. Should I build my own cloud?
Building your own cloud means that you have to invest substantially in infrastructure and in developing new capabilities. If your business has the scale to build a cloud in a cost-efficient way, including access to the technology, budgets, and the skilled resources to maintain the infrastructure, it can definitely be an opportunity. However, if you lack the scale of a larger enterprise, building a cloud solution probably won’t provide a competitive advantage, so it’s worth outsourcing to a partner who can meet your current needs and scale with you as you grow. Read the rest of this entry »
Fred Streefland, IT-Security Manager at LeaseWeb and Dave Maasland, CEO Eset Netherlands.
A version of this article originally appeared on Computable.
Recently we’ve had the opportunity (a quite fun and interesting opportunity), to visit a number of Information Security and Cyber Security congresses. During these congresses we were flooded with relatively ‘new’ developments such as Next-Generation, IoT (Internet of Things), IoT DDoS, Security Intelligence Platform, et cetera. The fact that some these terms have become ‘hype’ is not in itself a problem, but we did begin to wonder whether the security world may be looking at things in the wrong way and thereby missing the demands that need to be addressed.
In this article we will suggest a new way of looking at cybersecurity that stops viewing it as a goal in itself and instead as something that is directly connected to business needs. As it stands now, it seems that too many security-organizations are missing the mark.
Security can be quite complex, but its essence is quite simple. Security is nothing more than reducing or taking away risks, and making them visible so that the business can accept them and continue doing its work – nothing more, nothing less. To do this as effectively and efficiently as possible, we, as security-people, have to understand the business and not see it solely from an IT-Perspective but form the broader perspective of the business itself.
When starting from the business, we first have to identify, map, and categorize the risks for the specific business. Second, we have to determine, together with the business itself, which risks need to be dealt with in which order. When that’s done, the person responsible for security within the company has to set-up a security-plan that depicts how these changes are executed. When doing so, there should always be clear goals and deadlines. Ideally, this should be done in a ‘smart’ way, one step at a time, so as to not engage in too many projects at once.
Lesson 1: Start with the business (and its risks)
In today’s age of livestreaming events and concerts, the numerous and diverse amounts of mobile devices, desktops and TV’s pose a challenge for any content distribution creator. Julien Lehmann, Product Manager for CDN and Cybersecurity at LeaseWeb previews the new service of live transcoding, a service that simplifies your workflow, that will be launched during IBC 2016 in Amsterdam.
LeaseWeb kicked off its sixth quarterly Hackathon on Thursday, July 21st. The Hackathons are a chance for employees to step outside the usual routine and allow them to get creative, work together in new ways, and have fun. Participants are given two full days and nights to work on any kind of project whether it’s to solve a work problem, learn a new skill, or try out a personal project they’ve had in mind. Whatever it is, they have the complete freedom to try something new with the goal being to present a functional demo at the end of the second day.
Hackathons begin with a presentation where all of the participants gather to kick things off. Everyone receives a Hackathon t-shirt designed specifically for the event and then they hunker down to start work on their projects. Hackathon isn’t just for the engineering department and individuals from all parts of the company are encouraged to participate.
Perhaps someone in marketing has been thinking about a new tool that could help them do their job better. They might team up with an engineer to try and create that tool. New ideas and collaborations that might not have otherwise fit into the usual busy schedule are given the opportunity to be developed and tested. Several projects and tools that have been created during Hackathons have been integrated into day to day operations.
After working hard all day Thursday, participants took a break to have dinner and some fun. A barbecue spread was set out and there was plenty of chicken, burgers, salad, and beer to go around. A 45 meter inflatable obstacle course was set up in the parking lot and participants competed with each other to see who could get the best time. The winner completed the course in just over 30 seconds. After a bit more relaxation everyone was ready to get back to working on their projects. Some stayed late into the night and crashed at the office, others went home to grab some sleep before coming back in the next morning to finish up before the afternoon presentations.
At LeaseWeb, our CDN team focuses on delivering ultra-high performance globally for any content while remaining the most competitive player in the field. We process and monitor millions of requests per minute and that level of traffic requires a robust and flexible statistics platform that provide us and our customers with real-time accurate information.
Our previous statistics platform had several issues that didn’t allow us to get the most accurate picture of what was happening. The data was analyzed on the content-serving edge nodes. In order to consume as little resources on these nodes as possible, the data was sampled instead of counting every hit. The result was an approximation rather than an exact number. Another issue was resilience: the old platform had stability issues that might result in inaccuracies. We needed something that was reliable, wouldn’t consume edge-node resources, would record every hit, and would provide instantly precise counts for us and our customers.
Our goals for the new platform were as follows:
Aanand Prasad, an engineer from Docker, spoke about Abstractions Over Scale and Docker’s open-source software suite at LeaseWeb’s TechSummit in Amsterdam:
We wanted to get a little more insight into how tools like these are affecting the traditional ways of scaling technology:
LeaseWeb: A lot of times you see a gap between the engineers who manage servers and the developers who write the code. Why do you think this issue continues to exist and what are the common problems people face trying to fit two different environments?
Aanand: I think the reason it persists is two-fold: firstly they are dramatically different environments and there are very different problems with completely different concerns, at least underneath. My quixotic endeavor is to make the case that they don’t need to be. Which is an uphill struggle, because usually the job of getting something running in production and the job of getting something running in development are done by completely different people, completely different teams even who might not spend much time talking to each other. It’s nonetheless my hope that with tools like Docker and with abstractions like containers and networks and volumes, we can get to the point where the differences between those environments are minimized.
This is the second part in a 2-part series. Read part 1.
In my last post I gave an overview of how we started the process of changing the way we do agile development at LeaseWeb by setting goals, engaging our engineering teams, and developing a maturity model to get everyone working to the same standard. In this post I’m going to talk about how we set up our scrum teams, how we get all levels of the business involved in the development process, and how we calculate the cost to provide the most value for the company.
Our current Scrum teams are set up as follows:
- Product Owner – defines the priorities of the team; responsible for the order in which features are built.
- Scrum Master – in charge of the scrum process (coach): making sure the team does retrospectives, sprint planning, refinement, coordinating meetings.
- DevOps – Development and Operations in one team of about 5-8 people.
LeaseWeb’s annual Amsterdam TechSummit took place on June 2 at the Pakhuis de Zwijger, an old warehouse converted to a high-tech multimedia event center. The summit was sold out with over 315 attendees who came to hear a variety of presentations from professionals focusing on this year’s theme: Designing for Scalability.
Those who attended were a diverse assortment of software developers, operations engineers, and managers from companies both large and small. Many of the attendees were local but a good percentage of them had traveled from other countries including Germany, Spain, and even as far as Liberia. All of them were looking to learn about ways to help them grow not only from a technology perspective but how to scale up their engineering teams and how to anticipate and deal with the issues that result from that growth. The summit also provided a good opportunity to network with peers and learn about the challenges they face and what they’ve learned from past mistakes.
Terrence Ryan, a developer advocate at Google, gave a talk entitled Containing Chaos With Kubernetes at LeaseWeb’s TechSummit in Amsterdam on June 2nd. We sat down to find out a little bit more about his thoughts on the topic.
Interviewer: What issues are facing engineering departments who have just moved to containers?
Terrence: One of the large issues I’ve seen is how you manage and keep track of them all. Containers are ephemeral, so there is the switching over to the dev practices that supports that.
Having applications and architecture that is fault tolerant in the sense that these containers go away and that should be ok because the data is stored persistently somewhere else. All the app is doing is computing stuff and sending it back to the users. One of the big challenges we’ve seen and one that Kubernetes tends to solve is, “I have all of these containers, how do I keep track of them?” Those are the two problems we see come up. Kubernetes solves the management of the containers.
Read the rest of this entry »
In this blog post I’m going to cover how we are scaling our engineering department at LeaseWeb: where we started, the lessons we’ve learned, and how we are hoping to move forward. LeaseWeb was founded in 1997 and we currently have over 350 employees throughout the world with the majority working at our headquarters in Amsterdam. The engineering department currently has about 100 employees and manages 65,000 servers in seven locations (with more to be added soon).
In the past development was based on shifting priorities rather than planned business cases. Developers weren’t able to concentrate their efforts on thoroughly building, testing, documenting, and presenting a demo for one project before another more urgent one was moved to the head of the line. Operations and Development were working on different schedules and weren’t able to meet each other’s requirements to their mutual satisfaction. We wanted to change this.