Tag: english

This is a second post in what might become a series regarding DevOps, and DevOps transformation. Unfortunately for you, I speak my mind when I feel like it, so there is no master plan behind my ranting. First post was about choosing a strategy when transforming a managed services team towards DevOps.

This second step may not come necessarily after that first step 🙂 You get to choose.

In a way, I have the feeling that DevOps is close to what ITIL is : a toolbox where you can select which parts you would like to apply, and the way to implement them.

So new topic : how to target or build the team which will start the DevOps initiative in your organization?

There are several indicators that you can use to make this selection. None is an absolute, once again, these are pointers to which team would better succeed in applying DevOps principles. There is no sure shot, no magic finger method 🙂

The obvious criteria is to pick a team, of future team members that are already aware of DevOps, and willing to make the move. Of course these would be the people that will help you succeed in the first move, and show the rest of the world that it can be done, and bring very positive outcomes.

The second flag that should be raised is tied to one of the main outcome of DevOps : software delivery. If you have a team that is already struggling to get a reliable software delivery in place, and is willing to put the effort into building the organization and tools to get there, then you have a probable winner 🙂 On the opposite, if you try to convince a team that they need to move to DevOps when they are convinced their software is delivered efficiently and reliably, you’re going to hit a wall. Basically it would come down to convincing them that they are doing a poor job and are not even aware of that. Maybe not the right target for your first DevOps project.

The last one brings us to my favorite topic, outside of tech stuff : business outcome!

Of course, the aim of a transformation within your organization should always be mindful of the business outcome. Imagine you pick a team that is working on a neglected piece of software that no one cares about, and of which customers are just happy of the current situation. I do not think you would get the visibility and traction, not to mention willingness if you try to initiate your DevOps transformation in there. On the other hand, if you manage to get a team working on a new flagship product, that gets the attention of the CxOs, and has a need to show modern and reliable software delivery… you have a winner!

Once you’ve chosen your dream team, and start working, remember that DevOps, as always, is about people, not just tools.

The key thing to take away stems from common sense, and has been given by someone who did try and implement multiple Agile/DevOps organizations: “if you start with bad people and give them a smart way to work together, they won’t become smart by themselves”. Alright, I must admit the original quote was much harsher, but I cannot write it here 🙂

PS : I tend to keep these article short, and do not dive into each topic. This is done on purpose, not just by laziness. If you need to go deeper in each topic, just ask, or get a good read 🙂

I know, DevOps is still a buzzword. IT is often used to rebrand an old team or practice, and give more sexiness to a marketing slideset. I have seen it used to describe what is essentially an automation team within an Ops team. Good start, but missing the point.

Anyway, having been a major actor in a devops transformation, and witness to many, I wanted to give some advice to anyone out there patient enough to listen to me. I think most of what I am going to say will seem trivial, but it would help a few of us to put some words on what is happening to good ol’ outsourcing.

I am talking right now about DevOps transformation, but specifically when it happens to a Managed Services team, as in an outsourcing company, or an MSP. This is a difficult spot, as such teams should be able to provide support for DevOps organizations form their customers, and even help them.

I will skip the contract and SLA part, as it is a very tricky subject, at least for now.

I have seen two ways of approach the subject. First is full ahead transformation, no quarters, no mercy. The second is building a new team dedicated to DevOps, in parallel of the existing one.

I have only experienced the second first hand. It was an opportunity as we were bringing a new set of skills and customers into an existing managed services org. I chose to break from the past, and build a new set of tools and processes almost outside of the existing system. This creates the possibility to create and prove the viability of these new ways of working and interacting with your customers.

The difficult part is where you have to merge with the existing tools and processes. For example, we had to start with the monitoring tools we had, as we could not ask our 24*7 monitoring team to have multiple dashboards and tools. The fact that we were successful with the other tools and habits we developped allowed us to push for a new monitoring solution a few months after the initial move. And we kept the momentum after that 🙂

The other way I have witnessed, to transform the whole team at once, is challenging and cannot be carried by anyone on the team. I would advise that you start this path if you have a sufficient executive weight, or support from the executive team, because it will be a disruptive path. This is good, but the cost might be high, both in terms of people inside the team being disgruntled and maybe leaving, and in termes of your existing customers (and prospects) who might not understand what you are undetaking. The uptake is that you avoid having two different teams working with different mindsets and toolsets.

Obviously I would recommend reading the Devops Handbook, and the Phoenix Project, to get a basic understanding of what you are getting yourself into 🙂

Next up, I will try and help you target which team and/or customer would be a best fit to start your devops journey, stay tuned!

What follows below is an expression a purely personal opinion, based on my experience. Not everybody would agree, please excuse them 🙂

When I started working, and even during my studies, we had a rather negative view of IT researchers. We felt they were really smart, with deep technical knowledge,but on subjects that had no relation to what we would do on a daily basis. Knowing how a compiler works can be enticing, and useful in some edge cases of optimization, but we would never need that daily.

During the first 15 years, this trend endured. From what I could observe around me,nothing was very attractive for researchers in the IT world. We found them disconnected from reality, lost in theories or problems so far from our own.The first stir was felt with the advent of what would become today’s cloud giants (Google first). The issues they had around the volume of data they had to analyse, and the semantic analysis of said data pushed them to work directly with the world they were born from: research.

From my couch, this had been the subtle beginning of the change we can observe today. Researchers are wanted, hunted, asked for. We need their advanced knowledge and vision to solve very specific problems.

What changed, in my opinion, is the mindset, probably pushed by start-ups and digitization. We went from a product approach (what can I do with what I have) to a business solution approach (how can I solve this business issue).

And that changes everything.

Where we used to limit ourselves to the possibilities offered by a few products and set those up along predefined models, we are now able to consider the business issue, which has mostly nothing to do with IT. This problem is then translated into technical terms and we go look for a solution to said problem. And, if needed, we turn to research.

On the labs side, again in my opinion, what changed, at least in France, is that these teams now must get most of their budget outside of their usual public funding. The outcome is that we got closer. Just like in a Disney Christmas story (that’s the season!), we both did a step toward the other, and together we are stronger. 😉

Private market is now aware that the way the labs function and are financed is not the same. And it can adapt to that, because it allows for the creation of new solutions, with the aid of the best minds and techs, even if they do not exist, yet.

And public research has probably admitted that it could work with more specific projects, with hard deadlines and mostly a strict view onto ROI and real-world need.

At the end of the way, we find the emergence of Deep Tech startups. These are newborn companies that associate research on a very advanced topic, very far for industrialization, with business partners who can project what the use could be on the market. The ultimate bonding of research and business!

I have said it several times, this analysis is born for a very restricted view, mine,and just reflects my own perception of reality. I am no researcher, I am only an infrastructure engineer 🙂

About two years ago, Google announced the availability of TensorFlow processing units in its cloud.
They are dedicated microcontrollers built for training and running Machine Learning models. TPU are available within Gcloud as an execution platform for ML (of course, optimized for TensorFlow).
During the summer, they unveiled the edge equivalent of these TPU, which are named… Edge-TPU 🙂
These are very specific ASIC designed to execute ML models on an edge device, i.e. a small device close to the sensors gathering the data. This allows for a fast decision, without the need to send a truckload of data back up to the cloud.

But wait for it… Microsoft did just uncover a device called DataBox Edge. I know, the main purpose of this device is to provide a storage gateway to help you use Azure storage locally, and move the data between the device and Azure, hence the name. Bear with me, the path is a bit convoluted, and I would like you to enjoy every turn of it.
Databox Edge is also equipped with what has been called IoT Edge. This nifty piece of technology will enable you to run Azure-based workloads on an edge device, such as Azure Functions, Azure ML, Azure Stream Analytics etc. IoT Edge has been out in the open for about a year now, to be deployed onto compatible devices.
And, and that’s where we hit the Edge-TPU spot, also included in Databox Edge is a shiny new Microsoft hardware, called Brainwave. The name kind of gives away the purpose, especially after I guided you through the maze. Anyway, this chip is designed to run AI models on an edge device, and do it with impressive performance and efficiency.

I know, at this point, you would point out at the fact that it might again be a case of “We did it first!” from Google.

I’d like to focus a big difference between the two approaches. For once, I could not say which would win in the long term. In theory I prefer the approach from Microsoft, but that does not mean it will prevail (or that they would not change tactics and build something more like Edge-TPU).
The difference is that Google built an ASIC, whereas Microsoft used Intel FPGA to deploy its Brainwave architecture.
OK, this needs some explaining. First the names :
ASIC means Application Specific Integrated Circuit.
FPGA means Field Programmable Gate Array.

You see where this is going?
An ASIC is a very specific chip, designed to do only one thing, but optimized to its core. I should be able to execute one kind of job, but do it perfectly.
One the other hand, an FPGA is reprogrammable after its deployment, to be able to adapt to future needs. Its performance is close to an ASIC, but not quite equal.
To complete the panorama, going from specific to general use, we would then add GPU (Graphical Processing Units, as in your graphics cards) and then CPUs (ye good ol’ Pentium).

Microsoft took the path of versatility, whereas Google focused on a particular use.
As I mentioned, I’m not sure who has the best strategy, and whether there will even be a fight, but I am very curious to see both chips in the wild!

During the summer I had the chance to visit the Porsche Museum in Stuttgart.

And specifically, to try out two technologies I had never experienced myself before.

 

First we had a tour through the original Porsche workshop, and built some components of the 356. Of course, that was using VR glasses. I could not find the maker of the set, glasses and controllers, but they looked a lot like HTC’s Vive.

https://newsroom.porsche.com/en/company/porsche-museum-digital-offers-virtual-reality-experience-app-future-heritage-porscheplatz-stuttgart-zuffenhausen-15868.html

Anyway, the VR experience is really immersive and you have to be careful not to try to run around with the headset on.

The motion control needs some adaptation period, but after the first tries, you usually get very comfortable grabbing a hammer and forming the body parts of the 356, or holding the spray gun to paint your very own Porsche in your favorite color.

 

Overall, a good experience, the only limitation I see would be how to interact with the real world, or rather how to avoid bumping into the objects around you. And of course, it is a fully immersive VR, so you cannot see your body inside, apart from your arms, as you handle the motion controllers.

 

I can see some uses where you could have enough empty space around you to walk around and see a future building before the furniture and all the fittings are in.

 

I was definitely more impressed by the Hololens, mostly because the mixed reality opens up a lot more usages.

In that case the point was to be able to see inside an hybrid Panamera, and understand all the components and moving parts involved with the hybrid technology.

I had seen a lot a demos using Hololens before, but I was really curious about the level of interaction, and the finesse of the controls using specific gestures.

I have to admit the design is slick and the experience, although a bit disturbing, is both impressive and immersive.

I say disturbing, as the fact that some of the real world in your vision is overlaid by a virtual object can feel a little strange at first. You quickly get used to it, but it might be an adoption issue when deploying this technology into a daily worker toolset.

Nevertheless, I was able to quickly navigate around the car, see the insides and get some information and advice. The controls are pretty obvious and do not get in the way. And you are able to avoid anyone (or any wall) getting in your way while you tour the car.

 

There are so many businesses and industries where  this tech could be used :

• Any maintenance team for very specific hardware and high complexity tooling in the industry : airplane engines, industry automatons, remote stations where you could send any technicians that would be guided by a remote expert etc.
• Training for the same hardware, for your own maintenance team
• Anything involving 3D design : architecture, fitting and refitting of stores and offices, in store merchandising to ensure the right placement of all the items and furniture
• You could create guided tours, using augmented reality, to provide detailed information for the visitors

 

Argh, so many ideas!!!

Wow, it has already been almost a month since I started!

My new playground covers IoT and AI, and I am supposed to have a broad understanding of both.

Regarding IoT, my recent background helped me grow a solid groundwork for that. I am fairly comfortable with the concepts, and with the involved technologies. Moreover, I have a colleague whose sole purpose is to understand and build IoT solutions, so my bases are well covered.

When it comes to Artificial Intelligence, the coast is less clear.

First, it is not a domain where I have any background, neither in the theory (math, bio science…) nor practical (any implementation of AI).

Second, AI is the 2018 version of the Cloud in 2014 : everyone wants to do it, but not one has a clear definition of what we are talking about.

Last but not least, the very term AI covers almost anything, from a chatbot to augmented reality to self-driving cars.

My process has been a bit convoluted so far.

First thing I have tried was to register for e-learning (MOOC or otherwise) sessions on the topic. I have tried several, from OpenEDX to Microsoft AI school, to Google and Tensorflow. The content ranged from very high level, which was mostly too high for me, to algebra (which was a bit too deep for me).

Then I tried to read about the market. So I read a lot of whitepapers, from Microsoft, from DataIKU, from Forrester etc.

This was rather useful, as it gave me basic understanding of where the situation was.

I recommend Dataiku Machine Learning Demystified : https://pages.dataiku.com/machine-learning-basics-illustrated-guidebook

But still, I felt I was stuck in the theory and could not find the practical applications.

After some discussions with my usual suspect, Microsoft, I did have a look at their business uses cases and testimonies.

I have to admit, some of them were pretty interesting… however there is absolutely no information about the architecture or implementation of the solution, which left me wanting.

I finally found two Microsoft websites who did a good job of describing architectural templates, along with potential uses cases.

https://azure.microsoft.com/en-us/solutions/architecture/?solution=big-data

https://docs.microsoft.com/en-us/azure/architecture

This is where I started digging, and it made my mind spin with all the possibilities. You will have to wait a bit for the outcomes, and follow what SCC will be doing on this market in the coming weeks 😉

Last note, one of the smartest guy I have met at Microsoft, Frederic Wickert has started an AI business, and is writing, in French, to help debunk AI for us. I definitely recommend reading his posts! I admit I have not yet read the whole post, to avoid repeating everything here 😉

Nope, my new position is not dead yet, thank you very much.
What I mean by this title is usually a meeting in any IT service, after a major incident has been resolved, where all the team members who have worked on the incident gather and discuss what went wrong, and how to improve tools and processes to do better next time.

I specify blameless, as it is a very good practice to avoid finger pointing, generally and particularly in these meetings. If you want people to be honest and share their best insights, you have to keep in mind that these post-mortems have to cultivate an atmosphere of trust. The aim is really to find out how the events have unfolded, which information had been gathered, what went wrong, what steps were smart, which ones did not work properly etc.
For more information about that, I recommend some DevOps sessions and talks, like this one from @Jasonhand from VictorOps : It’s Not Your Fault – Blameless Post-mortems

But my point today is to write about another kind of post-mortem which I discussed with a friend a few months back.
The methodology of a post mortem could and should be used in different settings than just IT infrastructure incidents. It should be extended to sales, whether you manage to win or lose the deal. It could be applied personally to any job interview, even if there are usually not that many people involved. And it could be used after any major event in your life, personal or professional.

The main focus for me right now would be the sales post-mortem. In most companies I have worked for, the sales pipeline strategy is mostly to respond to as many RFP as possible. Statistically, it makes sense, as you are doomed to success every once in a while. In terms of smart strategy… let’s say I am not completely convinced. I tend to prefer a targeted answer to the cases where my team/company can bring out real value and help the customer while bringing attractive project to our team. I usually do not hesitate to forgo any RFP where there is nothing interesting or that puts us in jeopardy without bringing any value, or sexiness to our job.
When you have time to focus on very interesting cases and invest time on those, you would usually find this time useful, on short and long term. And you should take time, whether you win or lose, to have this post-mortem meeting with your team. It is good to get the feelings and insights from everyone involved about the outcome. And I mean everyone. The first stakeholder you should at least get feedback from is the customer. I try to build a trust relationship with a potential customer during the RFP process where we can exchange honest points of view about our positioning and the project expectations. During the process this helps everyone stay on the right track. And afterwards, it helps to know why you have not been chosen.

Beyond knowing, the most important aspect of these post-mortems is to implement some changes on your process, to be more relevant and have a better chance for success the following time around.

And that’s it for early morning musings, ’til next time!

After a long summer break, getting back to writing is a bit difficult, so here is a first post for a new era. I’ll be switching jobs early September, so there might a slight variation in the subjects I’ll write about.

As highlighted in Gartner 2018 Cycle of Hype study, IoT is now a mature tech and we will see more and more large scale projects being deployed in the wild. I would like to expand a bit about what it entails to start an IoT initiative, whether it be to design a new product to sell, or to gain some insight and improve your own processes.
The steps are familiar to anyone who has ever come close to a project in his/her life:

1. Design the solution
2. Gather the requirements
3. Choose the components, protocols
4. Build all the processes (logistics, operations, IT, support)
5. Market and sell
6. Maintain and deliver new functionalities

In terms of project management, there is nothing to learn here. I just wanted to highlight the specifics of an IoT project for these steps. There some particularities due to the type of project, or just points to remember that should be obvious but are often forgotten.

Design the solution

What I mean here is a high level design, functional, that will describe what you are aiming to deliver to your users or customers. Nothing fancy, nothing technical, just plain business.

Gather the requirements

Nothing new here, just make sur you include the future functions and the way you are going to develop. For example, if you start with an MVP (Minimal Viable Product) and build from there in short cycles, you need to have a long term plan/strategy that will keep everything on track. And this plan should help you define your long term requirements.

Choose the components/protocols

This is a technical step, rather complex to execute today, as there are so many solutions to one single question out there. And you have to keep in mind the current state of the art, along with what you expect this state to be in 3, 5 or even 10 years.

Build all the processes (logistics, operations, IT, support)

From my experience, this a often disregarded step, even by some companies that have been in the industry for decades. The simple question is : you are going to deliver a product (physical) to your users. What happens when the product breaks? Who are they going to call (and no, the answer has nothing to do with an 80s movie 🙂 ), how are you going to manage your replacements, stock, warranties etc. How do you handle servicing the device? Remotely, using your current support team, or locally? One specific suggestion, coming from experience : remember to include the ability to remotely upgrade your firmware 😉

Market and sell

Nothing to declare here. This should be rather standard. One word of advice : most IoT project that succeed build on their ecosystem and integration of new functionalities. You should probably add that to your strategy, and to the marketing materials.

Maintain and deliver new functionalities

This point relates both to the maintenance and support I have raised earlier, and to the lifecycle of your product.
Think about the many product we have seen with an incredible starting point in sales or customer acquisition, that dropped of the board after a few weeks, because nothing happened beyond the first wow effect. There nothing more infuriating, as an end user, to have a product with no bugfixes, or without any new functionalities beyond what came with the product out of the box. For example, take a mobile game, Pokemon Go : they had an amazing start, with millions of users daily. But, as the hype faded out, rumored functions and abilities did not come out, and the game statistics went down.
https://www.wandera.com/pokemon-go-data-analysis-popular-game/

The short version is : a connected product is a product, physical, with all the requirements that should be included in such a project. Do not go too fast when your Proof Of Conecpt works. Think long term, and try not to be dazzled by a partner or consultant that show off what a POC platform does on a demo screen 😉

Almost a sponsored post today, or better : a shared announcement.

You probably know that I am following Kubernetes rather closely, especially managed Kubernetes services (AKS, EKS or Openshift for example). One domain where these offerings have been lacking is network and security.

It is still a very sensitive subject for our customers, for containers related project, and still for public cloud projects. Security and networking teams have trouble adapting to the public cloud paradigms and architectures. There some fear of loss of control, some base fear of the unknown, and some real worry about how to handle networking and security.
Kubernetes (and the other orchestrators) adds another abstraction layer on top of the existing public cloud platforms, which does nothing to alleviate fear, to say nothing about complexity and transparency.

There are some very good solutions out there to manage network overlays into Kubernetes. My favourite is Calico, but you may like any of those. I’ll stick with Calico for a simple reason, which you will see below.

Microsoft and AWS are both working hard to provide a network overlay into their managed Kubernetes offering. They each chose their own path, but we will get to approximately the same point in a short time.

Thanks to Jean Poizat, we have the two announcements.
1) From Calico for Azure : https://www.tigera.io/tigera-calico-coming-to-azure-kubernetes-service-aks/
2) For AWS : https://itnext.io/kubernetes-is-hard-why-eks-makes-it-easier-for-network-and-security-architects-ea6d8b2ca965

The summary is that Calico will be integrated into AKS in a few weeks/months, and EKS will include AWS CNI.
And that is exactly what we were waiting for, along with our customers : managed Kubernetes, with security!

Depending on how you consider things, it is the third time that it happens to me.
Being able to design, under certain limits, your own job, is an amazing opportunity.
I will not go into too many details as some of it is work in progress, but the process was amazingly energizing and I wanted to share a bit of that energy.
For my current job, I met my future boss on the recommendation of a former colleague. We discussed many things, from ITIL to Managed Services, and also public cloud and the need to get dev and ops team closer. We went through those kind of talks several times, at least four if memory serves. We went from a job which look like an Ops engineer/ITIL practitioner, to something closer to an Azure tech lead.
In my previous position I also had the opportunity to be offered a promotion, and been able to discuss some of the content and responsibilities of the future role. I was also able to step down when time came for me to admit that it was not an ideal position, for me or for the company. Which was really appreciated, at least on my part.

And once again a few weeks ago, I was called out of the blue by a colleague’s boss. He started to discuss his own future and what he was trying to design. He wanted to build something new, and was searching for a partner to build that together. And in that scheme, he discussed a position very similar to my dream job, and offered it to me.
I almost fell off my chair.
At that point I was ready to accept, without having any more details about the exact role and responsibilities, or even the salary. That’s where my future boss started to ask me what I would include or exclude from that job description, and how I could make it my own. My mind just froze.
It took some time for me to recover and start thinking again. After some lame jokes, we discussed the position, and what we would like to build together. It took us several meetings and calls to see through the fog, as we are really going to build something new together, and we cannot rely much on what exists around us.
The last funny thing to happen was that my next interview was with the CEO of the company, who was convinced by the both of us in less than 35 minutes. I could not believe my luck in getting there.
Anyway, that’s it for the bragging post. I really needed to write that down to make it real (even if I signed and will start by the end of the summer 🙂 )