Saturday, July 15, 2017

Network Engineer Evolution

About two years ago I made a learning roadmap for network engineers who want to transform their skills towards Software Defined Networking. I presented it at various events including Cisco Live. It was good, but it looks like I didn't provide the full story. So let's discuss it again, and we will start from the very beginning.

Any network engineer who just starts his or her career today will begin in Phase 1: as the User of networking products where the engineer only knows how to configure the product, hopefully by reading the documentation from the vendor's website first. This type of engineer is what I call "Config Monkey" (sorry, monkey!). If you think you are still in this phase, please don't get offended: I started my career here too. There is no innovation at all, only follow the manual to make the products run.

Then we will move to Phase 2: as Advanced User of networking products. This is the phase where the engineer understands how networking protocols work in detail. He is a domain expert now and can start fine tuning the protocols to optimize the infrastructure. IGP timers, fast re-route, BGP attributes etc. and the engineer should go back and forth between the protocols standard and how they get implemented in vendor's products. So all the fine tunes are based on the 'knobs' provided by the vendor. And by nature, phase 2 network engineer possesses the skill to do troubleshooting as well.

Phase 3 is when the engineer starting to become System Integrator. Even it's similar like Advanced User, but now the engineer must deal with different network functions from wireless access and top of rack switches to security devices, firewalls, domain names, caching, network-based storage, content delivery, application load balancer and so on to provide end-to-end services to end users. He is aware about design trade-offs of various choices. There is still no innovation yet, however by now the engineer has possessed the skill to design, integrate and fine tune complex system all the way to application layer.

SDN and network virtualization comes to the picture in Phase 4: Advanced System Integrator. The system now consists both physical and virtual components. Overlay network runs above the underlying physical infrastructure. Virtual infrastructure has multiple controllers and managers that need to be integrated between each other. Network services have life cycle from initiation until depletion so it must be monitored. Phase 4 engineers talk about APIs when integrating different components. Both physical and virtual networks must run in harmony to provide end-to-end connectivity for the users to access the applications and services.

Once the engineer passes Phase 4, this is the point where he can decide to take either one of different technical paths: first, is to move towards the business and start becoming Solutions Architect. Architect must translate business requirements into technical specifications, and provide integrated solutions to answer the requirements. We can live happily ever after here. I know it because I used to be in this phase for many years when I work for Cisco.

The second path is like what Morpheus described as the red pill: stay in Wonderland and learn how deep the rabbit hole goes. We can choose to stay as engineer to go even deeper in the next two phases.

Phase 5: Contributor. Phase 4 engineer assumes all components will just work when they are integrated, just like playing Lego. Yes, she still needs to understand how one component consumes the API of the other component. But in reality the integration is not, or never, that straight forward. Engineer moves to phase 5 once she starts developing few components to make the system works smoothly. It could be as simple as making automation script using SDK provided by the product's vendor. Or create new driver for an open source platform to connect to specific network device. Or customize the current module of one software to make the system runs. Engineer writes code, understands software development workflow, and fills up the missing ingredient to build one solid system.

Phase 6 is the phase served for Creator. This is the God-mode in Network Engineering. Engineer can look at the current network protocol and decide to invent the new and (hopefully) the better one. When building a complex system with multiple products from different vendors, engineer can assess if it is required to build new software component to have a successful integration. Phase 6 engineer thinks about scalability all the time, centralized vs. distributed model, and about the workflow from beginning of user's request until the service is provided. She generates ideas require to solve complex and open-ended problems. She thinks agile and runs iteration to optimize the system. Engineer in this phase is the one who translates business intent into automated workflow execution to deliver the service.

So let's look at my T-shape SDN Skill Transformation path and try to relate it to the 6-phase of Network Engineer Evolution above.

Obviously you need to be at least a Phase 3 engineer before looking at this path. To start the journey in Phase 4, you need to learn virtualized infrastructure for network, compute and storage as well as the managers and controllers to manage them. Learn abstraction and modeling. Then learn software architecture and engineering. Get involved in software development. Start writing code or optimize existing code to move to become Contributor in Phase 5 and beyond. Or if you decide to take Solution Architect path instead, switch the mindset and learn business skills.

I won't mention any vendor's product, or any vendor's certification, anymore in the evolution. Understand the expectation of what engineer in each phase has to deliver, skills that must be possessed, then make your own judgement to decide which vendor or which certification program (if needed) you want to use in your learning process.

And please don't be mistaken to think I self-proclaimed myself as a Phase 6 engineer. I made decision a while ago to become Product Manager instead, that provides me opportunities to work with many creators to build the next cool things in networking.

Final thought: it's okay to start as monkey once. But knowing where we are, and where we want to be, can surely help to plan how to get evolved.

Tuesday, July 04, 2017

One Year Ago Today

One year ago today, fourth of July, was my first day at Google Zürich. It’s been a very interesting journey so far, and from the beginning I spent most of my time to focus on three things: switch to Product Management to learn how to build great product, work on scalable Enterprise networking solution from cloud-based SDN to intent-driven automation, and learn data analysis in-depth from data visualization all the way to Machine Learning, to be used in product development.

As you notice, I rarely post new blog since I joined the company last year. And I find it quite difficult to find any active blog from other Googlers too. Just like any tech company, when we joined all of us signed an agreement containing various obligations including the requirement to hold proprietary information and trade secrets in strictest confidence. But I believe there should be some non-confidential things that we can share in our personal blog.

So why can’t we blog?

First, we are very busy here. And not because we have to, but we choose to.

I mean, there are just too many interesting things to do and to learn at Google. If you work for the best company in the world that empower every employee to innovate, in everything we do, you surely want to spend time the best you can. We write a lot, like writing product requirement document, design specification, or execution plan, but then we will be busy building the product and getting things done.

Second, most of us feel that what we do is not new.

There are so many talented people in Google with great ideas and executing them everyday. So unless we innovate something completely new, or improve something to make it 10x better, most Googlers think what we do is not new, it’s common, and we assume everyone must has known this already so it’s not worth sharing. That could be true for within Google but some of the ways we do things here (again, the non-confidential things) could be very useful for people outside.

Third, we are trusted with so many confidential information, we don’t want to unintentionally share them.

Google culture is very open. Every Noogler, new hire, usually get access to Google codebase within the first week in the company. Employees share their salary and bonus in Google sheet. There is a weekly company-wide all-hands meeting called TGIF where top management to various teams present about a product Google has been working on, and then take any questions from the audience. Any questions from old timer to new hire and even intern. And we are all trusted not to leak the information to outside the company.

This has created the culture of trust, that make us believe we are truly part of the family. And as family member, you don’t want to break the trust by sharing confidential information even unintentionally to outside the family.

(Read here about the impression of company culture from an intern)

Having said those, I will still try to continue blogging here.
Watch this space.

Thursday, January 19, 2017

2016 Year in Review

Every beginning of the year I usually review what I have done the past one year, make notes, and build the plan for the upcoming year. I made many mistakes in the past, did things I’m not proud of, however I use them as opportunity to learn and try to be better next time.

Early 2016 I found that my startup company was competing directly against Cisco (that was still my employer at that time). That was quite surprising. I founded that company in 2012 initially as my pet project, the lab for my MBA, where I can practice whatever I learned from the business school. My pitch for the startup was simple: we do what Cisco (or Cisco Services) will not do. We built online learning platform to learn Cisco certification using group mentoring system. We run physical network audit. We did system integration projects to interoperate Cisco products with any other vendors.

However, since late 2014 the engineering team in my company have evolved. They grew skills in network programming. The team put more focus on Software Defined Networking (SDN). They built lab to validate Network Function Virtualization (NFV). And then the team started to develop our own SDN Controller and Network Automation platform.

Then customers started to come. Customers wanted SDN solution, NFV infrastructure and network automation, but the ones that are vendor-agnostic. They came to my company. They asked the team to bid in the project. That’s when finally Cisco started to notice because they were bidding too.

Early April I decided to resign from Cisco to run my own company as full time CEO.

Mid 2016 I received an offer from Google to join them in Zürich, Switzerland. From April I have built company vision for my startup and laid multi-year strategy, and I knew they can be executed under the current leadership team even without me. I also have personal reason to move my family to Europe. So I agreed to leave Dubai and started working at Google from July.

Even before I joined Google, I already made a plan of what I will learn in the company. Google is the right place to learn so many interesting things, but for 2016 I just wanted to focus on three things:

1. Learn how to build great product

“Behind every great product, there is a great product manager” - Marty Cagan

Google has created 7 great products with more than a billion users using each. And as Ben Horowitz wrote: a good Product Manager is the CEO of the product. A Product Manager combines business, technology, and design in order to discover a product that is valuable, feasible, and usable.

Product Management is above all else a business function, focused on maximising business value from a product. A Product Manager understands the technology stack from the product, and most importantly understanding the level of effort involved is crucial to making the right decisions. And Product Manager is the voice of the user inside the business and must be passionate about the user experience.

2. Continue to learn about SDN, but the scalable ones

Deep down inside I’m still a network engineer. I’ve been focusing on SDN & NFV since 2014 when I was in Cisco. Google has been using software-based solution in its network infrastructure even before the world called it SDN. However, I’m currently interested with highly scaled SDN solution using cloud based platform.

And I’m very interested with transformation path for any Enterprise company to evolve towards a fully automated network operation. I even built the five levels of Autonomous Network, mimicking the levels in Autonomous Vehicle, and currently working on the fifth level: intent-based, policy-driven, zero touch networking.

3. Learn Data Analysis to Machine Learning

Google is the best place to learn Data Science. Period. With Google Brain and DeepMind as part of the Alphabet group, this is the only company I know that puts Machine Learning first in every aspect of its products. Currently I'm focusing to learn about data analysis, data vizualisation and predictive analysis using machine learning.

The three things above are still my valid learning plan for 2017.
How about you? What is your learning plan this year?

Build great product.
Cloud based SDN solution.
With data analytics and machine learning.
“Building the network of the future”. Got it?

Friday, April 15, 2016

I'm Leaving You

No. It’s not you.
It’s me. It’s always been me.

I remember the first time we met. It was early 2000.
I was young and just graduated from Mechanical Engineering.
I didn’t have any job.
I was desperate. That’s when I met you.
It was like love at first sight.
I spent sleepless nights just to know you.
And more and more I spent time with you, more and more I love you.

I spent time with several others, but my mind and heart were always be with you.
I knew I have to get to you, at any cost.
Even if I had to sacrifice.
Even if I had to leave my home in Dubai.
Even if I had to leave all my friends behind.

Finally in 2006 we were officially together.
I remember it was November, in Singapore.
I couldn’t describe how happy I was.

I traveled many countries in Asia Pacific for you.
I never asked questions. I was a very happy man.
And you invited me several times to visit your home in California.
I was living my dream.

You asked me to move back to Dubai with you in 2008.
A request that I didn’t refuse nor question at once.
You made me travel to many countries in Europe and Middle East.
You made me witness the beauty of African countries.
Once you even asked me to spend time in Central and South America.
You gave me chances to show myself at your special events.
You made me happier.
You made me a better man.

As the years went by, something changed.
Something inside me wanted to be unleashed.
I wanted more.
I’m still in love with you, but I wanted to do more.
I wanted to go out and meet others.
I wanted to be more useful, wanted to make greater impact.
I grew impatient and wanted new things to happen quicker.
I wanted to use my spare time to talk to others, to try to inspire.
Wanted to share my enthusiasm with others.
And even though whenever I went out I always spoke about how wonderful you are, I could feel that you started noticing that something has changed.

We’ve been together for quite some time.
We’ve been through some high and low time together.
Knowing how far we have reached together, I should be able to handle such thing like this.
I was supposed to be able to convince you how much I love you.
I was supposed to tell you I’m still the same person, nothing has changed.
I was supposed to be a better man.

However, this time I let myself to make a different decision.
I wanted to break free from the relationship.
I admitted I was scared at beginning.
I was scared to make the change.
But I believe it’s necessary.

It always hurts to say goodbye.
But this is the right thing to do.
This is the best for both of us.

I’m leaving you, Cisco.

Thank you for our time together the past 10 years.
Thank you for giving me the special feeling the past 16 years.

It’s time for me to move on.
To chase my destiny. To build my own legacy.

You were, and will continue to be, my special one.
Goodbye for now.

Monday, March 21, 2016

Big Data vs. SDN

During one Software Defined Networking (SDN) workshop I hosted in Jakarta early this year, my friend was presenting a session with thought provoking title: Big Data vs. SDN. He is the CEO of a Deep Packet Inspection (DPI) and Data Analytic company that relies on Big Data technologies, so I can understand why he brought up such topic. But just like the new movie Batman vs. Superman that will be released this week, should the two heroes are fighting each other? Should the two are competing between each other? Big Data and SDN obviously solve different problems. And the way I look at it, they are actually closer to work together to deliver platform to help business with CAPEX reduction, OPEX reduction and agility in delivering new services.

The most natural approach to define Big Data is with the bigness. However according to Gartner, Big Data is defined as “high volume, high velocity and/or high variety information assets” that can be used to improve decision making and provide better insights.The majority of raw data, particularly Big Data, does not offer a lot of value in its unprocessed state. Big Data Analytic is the process of examining Big Data to uncover hidden patterns, unknown correlations and other useful information that can be used to make better decisions.

SDN paradigm to separate control plane and data plane has objective to create network abstraction for faster innovation. We can create new network applications without any need to interact directly with the actual network devices, instead our applications just need to consume the APIs provided by SDN controllers. SDN can be coupled with NFV, Network Function Virtualization, to run network functions and software on any open standard-based hardware to reduce CAPEX, OPEX, power and space. The orchestration of the network based on SDN and NFV can automate, provision, and interconnect all physical and virtual network resources.

Last year Gartner showed in their Hype Cycle that SDN & NFV is moving from hype to reality. The hype reached the peak on mid 2013 when most people thought that central controller using OpenFlow would control basic network devices completely, all network functions would transition to run on x86 platforms, and this paradigm would apply across to all aspects of networking. However, by mid 2015 most people understood that SDN & NFV implementation will use hybrid control plane consisting of a mix of distributed and centralized control plane, the network will consist of a mix of physical and virtual network functions, and SDN solutions are based on specific requirements / features and use-cases driven approach.

How can SDN & NFV be connected to Big Data & Analytic?
SDN applications must be responsive to the world in which they exist. If we are going to use SDN technologies to auto-provision network services, and turn the network to be truly dynamic, we will need to have feedback loops to ensure the desired behavior is actually occurring after a change is made. The natural progression from manual to automated will pass first through network analytics. As Michael Bushong wrote for Infoworld: "Ultimately, the promise of SDN will be inherently tied to the information that surrounds the network and drives the decisions that make SDN applications interesting. With more and more endpoints driving increasing traffic to a growing number of users, that adds up to big data."

Two weeks ago I was in Brussels to try Cisco WAN Automation Engine (WAE), a sample implementation of network analytic for Wide Area Network. To many network operators and service providers, WAN are oceans of uncertainty. Resource-constrained and multivendor, WANs produce delays and outages in far-flung and sometimes remote areas, posing a special set of issues that are distinct from those we see in data centers and access networks. WAN bandwidth is the most expensive bandwidth in the network and failure impacts are large.

WAE allows service providers to respond to overall traffic growth in terms of keeping the whole network stable and not just provisioning to traffic peaks. WAE offers what-if scenarios and failure analysis, empower the customer to be able to examine the impact of network failures in more detail, and was able to adopt a new policy by only upgrading links that were in danger of dropping packets on single-circuit failures. Using predictive analytics capabilities of WAE, we can build a powerful SDN solution that allows us to deploy and optimize innovative new services, such as global load balancing, bandwidth calendaring, bandwidth on demand, and premium network routing.

So we have seen how Big Data (Batman) and SDN (Superman) can work together, who should be the Wonder Woman in this story? It is obvious, isn't it? Internet of Things.

IoT and Big Data relationship forms Fog Computing, that uses one or a collaborative multitude of end-user clients or near-user edge devices to carry out a substantial amount of storage, communication and control, configuration, measurement and management. Fog computing can be perceived both in large cloud systems and big data structures, making reference to the growing difficulties in accessing information objectively.

With IoT it means everything is now connected. With huge explosion of number of endpoints, IoT will require a network that is not only self-provisioned, but as well as adaptive, dynamic and responsive that can be achieved with SDN. The network must provide broad and deep visibility into network traffic flow patterns too, the network must become the sensors, and this information can be used in different implementation such as for network security where by leveraging rich threat intelligence information allows for more rapid identification of security threats.

When the three superheroes are together, what should we call them?
Introducing AI @ Computer Networking. JP Vasseur, a Cisco Fellow, during Cisco Live Milan last year presented this as Self Learning Networks. Ex-Cisco CEO John Chambers mentioned this terminology in his keynote for Cisco Live 2014. Packet Pushers call this Machine Learning for Networks.

Artificial Intelligence, a singular consciousness that spawned an entire race of machines, as Morpheus explained to Neo in The Matrix back in 1999, is coming to unexpected places like computer networking. David Meyer, CTO & Chief Scientist at Brocade and formerly at Cisco, wrote the following notes: "it doesn’t take a lot of imagination to see how sophisticated unsupervised machine learning will revolutionize many of the more complex network tasks that are solved today in (much) less dynamic ways. For example, problems such as data center orchestration could benefit greatly from this technology. Clearly functionality that we’re talking about in networking these days, including Network Function Virtualization, Service Function Chaining, Mobility and the like are great candidates for treatment by Deep Learning. More generally, orchestration and optimization of Compute, Storage, Networking, Security and Energy (CSNSE) are prime candidates for consideration by Deep Learning technology. And consider what DevOps-style automation might look like when combined with Deep Learning."

Even IBM believes Watson, not SDN, is the future of networking. IBM's cognitive system demonstrates the power of artificial intelligence which will run our networks and transform IT management. They even come up with another cool name: AI-defined networks. And it won’t be about automating routine tasks, programmatically managing networks or providing a platform where humans create evermore clever access policies. Instead, we will teach machines that watch our network traffic, monitor our applications and cognitively recognize novel behavior on our firewalls.

So SDN is not the future of networking. And I agree. It is simply part of network evolution that is happening right now. If your network has not embraced SDN & NFV technologies, it is not a question of If but When. SDN will happen eventually.

The future of networking lies on the combination between SDN & NFV with Big Data & Analytics, and IoT. The three superheroes are working together and we may call them Self Learning Network, or Self Managing Network, or AI @ Computer Networking, or AI-defined Network.

Now let's just enjoy Batman vs. Superman movie.

Thursday, February 25, 2016

SDN Warriors All-In-One VM

SDN Warriors open community Facebook group today is releasing All-In-One VM v1.0, a Virtual Machine that anyone can run in PC or laptop to learn SDN & NFV skills. The VM runs Ubuntu OS and contains pre-installed OpenStack, OpenFlow network simulated by mininet with OpenDaylight controller, physical router simulated by dynamips, simple web portal and Network Manager written in python created by Riftadi SDN Warriors group admin. The VM is not created nor endorsed by Cisco, Canonical, ONF, Linux Foundation or OpenStack community, so please don’t ask for any support whatsoever from them. One way to use the VM is: by using only a single click in web portal we can provision automatically new vrouter VNF as OpenStack VM, configure OpenFlow network to connect physical router and vrouter, then configure OSPF routing in both physical and vrouter. You can start with this simple use case, then expand it as part of your learning. The VM is free to download and available here:

Thursday, February 18, 2016

What a Week at Cisco Live Berlin!

What a week at Cisco Live Berlin! First time presenting BRKSDN-4005 in front of 180 people, many are CCIEs. Brought one talented Indonesian who demonstrated All-in-one VM to learn SDN & NFV at home, using a single click on web portal to auto provision physical router, openflow with ODL, router VNF on OpenStack KVM, from Network Manager he wrote in python. And btw he has 2x CCIEs ;-)