Come for the rant, stay for the golden nuggets, walk away knowing how to ship better software for fuel retailers.
Details to my session as follows: https://retail-code.com/sessions/case-study-the-road-to-continuous-delivery-and-beyond-in-the-retail-world/
Super thrilled to be holding two talks in @code_europe in sunny Warsaw on the 7th of Dec! The first talk will be about tdd with serverless, automation, and tooling. I will touch on Cloudfront and Lambda@Edge with liberal sprinkling of node.js and mocha. Ultimately piecing the buzz word alphabet soup together with Jenkins in a live demo format 🙂 If the demo gods are with us, you are in for some docker in docker in vagrant spawning dockers type of inception mad science.
Second talk aims to cover the usual devops circuit and the curiosities for the macabre; a transformative journey and a deep dive. Having grown up with Bill and Ted’s Excellent Adventure as a budding young lad, I am happy to ground the subject matter in a light hearted manner this time 🙂 #strangethingsareafoot
Very grateful to be invited to speak in the International Forecourt Standards Forum (IFSF) Innovation and Collaboration Conf 2017 in Paris this year 🙂 If you are in town, swing by or hit me up on twitter, and let’s talk #docker #microservices #apis and #devops!
*Speaker Announcement* @yveshwang will be joining us in #Paris to discuss micro-service architecture #IFSFconf2017 https://t.co/3S3uIMO9TG pic.twitter.com/ufKR7aTNsb
— IFSF (@IFSFonline) August 31, 2017
You know you want to 🙂 Come hang for the rant, but stay for Mårten Rånge‘s session on Property Based Testing.
update 13.04.2017: slide deck avail here: https://github.com/yveshwang/presentations/tree/sthlm/impress.js/gbg
Here are some free and honest advice on the topic of EU General Data Protection Regulation (GDPR) – because frankly we are a little tired of the corporate jargon.
Being a good custodian of personal data does not have to be scary nor difficult. I happen to think it is quite straight forward, though it can be a fair amount work. Most important piece of the puzzle for the data controllers or processors is that you will require a devops/fullstack team. If you are an old school enterprise, then you should have gone through some kind of I.T. transformation to embrace and put in place principles of devops. This is because during the process of working through the various controls surrounding personal data, chance are things will be missed, particularly if you have a very large portfolio. The only sure thing is that as an organisation, you can work in an iterative, lean and agile, and collaborative manner.
Some unsorted advice in bullet points below.
The hard truth is, GDPR is not in anyway shape or form finite or deterministic to warrant an engineering approach or a scientific model as basis for discussion. It is more likely that the process of addressing GDPR will be personalised and unique to each company. Ironically, it is a little like personal data itself. Most importantly, if you do not meet some of these devops requirements, you might want to start there first, and fast.
<rant>
I have been racking my brains trying not to sound like a giant multi level marketing douche on the topic of EU General Data Protection Regulation (GDPR). This is my nth attempt at drafting this blog post and literally the writing has gone from selling fear and greed to regurgitating some hallelujah self-help Secret-esque scheme that regurgitated the same old concepts like “consent”, “transparency”, “pseudonymisation”, that is suppose to concretely address “privacy by design”, “obligation of data controllers”, or “data subject rights” etc. Well, at least I will portrait an image of misguided confidence whilst oozing a ton of leadership if I may say so myself. Nevertheless, I personally feel some simple, down-to-earth steer is needed on the subject matter and I have decided to put it out to the universe.
</rant>
Speaking in DevOps Vilnius this year and still feeding ’em enterprises a strict diet of #lean #devops. Come say hi! http://sched.co/9qWc
#Devoxx and #devoxxpl, what a fantastic experience in a wonderfully geeky city that is Krakow. The conference was a massive eye opener, from talks on the bleeding edge to discussion not far from the old school governance and architecture (yes, people still care about these discussions apparently). Indeed I felt very grateful to have presented my talk in #devoxx this year, mostly sharing our fun enterprise transformation journey and repping the Avengers (shout out to Warsaw yo!). I found my session to be very enjoyable particularly thanks to a very receptive audience. Thank you from the bottom of my heart 🙂 You all rocked!
One speaker that did stand out for me today was a talk about development culture, particularly about the lack of business sense developers had, and that these nerd are considered cost centers because they only wished to essentially waste funding to try out new tech. Seriously dude… you are the Donald Drumpf of devops and I am sub blogging you (I guess this is a thing now). It’s not like business side can’t be a cost center either and it is pure naivete to put them up on an undeserved pedestal.
I hope that particular message was not taken to heart by the audience, but instead I would say this. To my fellow devops and developers and admins alike. Thirst for knowledge. There is nothing wrong with chasing bleeding edge. This is the core of innovation and startup mentality.
Disruptive tech and business models like Bitcoins, Uber and AirBnB should be evidence enough that you do not need antiquated F.U.D. and this strange fixation on so called “business sense”. Grow as technologists and blossom into creative innovators. Give back to tech and your open source communities. Do not listen to the Donald Drumpf of devops and his spiel based on self doubts and guilt trips. Chase knowledge.
Devops is culture.
Awesome sauce! I am sooooo very excited 🙂 Avengers assemble!
Devoxx PL
One does not need to look any further than World of Warcraft (WoW) to appreciate the beautifully enacted artistry that is teamwork. And it is exactly what an enterprise I.T. needs. Picture a cross functional and multidisciplinary team of rockstars working towards the same goal. This blog is about drawing a comparison between staffing up a devops team for product development in the same manner as running a team through an instance in WoW, dispelling any F.U.D. along the way, and getting that epic win for the enterprise.
Suffice to say as a developer, one spends countless hours in front of the PC. It is fair to say that some of us would at times play games together, or WoW to be exact. As Jane McGonigal @ TED 2010 spelled it out for us, that gamers are people whom has picked up the skill of solving extremely difficult problems in an collaborative and multidisciplinary setting. They are self motivated and extremely committed. The rationale can be mapped to the addictive feeling of an epic win. Achieving the insurmountable or being constantly on verge of an epic win is something quite familiar in the context of software development. I would argue that a typical software craftsman share a number of qualities with a successful WoW player:
Why software craftsman matters? Because quite frankly, most business are going to be software houses. Digitisation is about doing things right by I.T. and your nerds are now your core business.
Gamers always believe that an epic win is possible, and that it’s always worth trying, and trying now. Gamers don’t sit around. Gamers are virtuosos at weaving a tight social fabric.
Jane McGonigal, Feb 2010 @ TED
The trick here is to make our daily work meaningful and as important as any other world saving quests. Provided time is not spent in meetings or corporate risk management theatre, I would argue most of what we do conjures up the same feeling of achievement. For example:
These activities are all mini epic wins for me personally. We are your hipster superheroes after all.
If you are distracted by PCI-DSS, SOX and the like, start writing some code and run a few instances in WoW. Experience the magic first hand. And don’t forget to read this and this during your down time. Get over the smoke screens and get back on track with the epic wins.
“And this argument – that collaboration between silos, or even cross-functional teams, is forbidden by regulation or “best practice” – is an example of what we in the consulting industry call a bullshit smokescreen.”
Jez Humble, 19 October 2012
Assuming you are being innovative and building things from scratch, typically in WoW you need 1x tank, 1x healer, 3x DPS (Damage per second). Translating to software terms, you will need 1x tech lead, 3x fullstack devs, and 1x sysadmin. A 5-persons multidisciplinary team goes a long way. Let me break this down.
Tank/Tech lead: In WoW terms, your role is to take all direct damage for the team and be the leader of the pact. You draw and keep the attention of the epic boss to youself. You shield the team from a complete wipe. In software terms, you are a SCRUM master or the spiritual tech leader of the team. You take the unnecessary meetings and shield the team away from distractions. You might code a little or contribute to testing and test automation, or you might be a UX specialist. One of your main task is to free up time and space to enable your rockstar coders to code; aka DPS down that epic boss.
DPS/Rockstar coders: In WoW terms, you deal damage, hard and fast and consistently over a period of time. You are much more squishier than the tanks and you should not pull aggro to yourselves and burden the healer. In software terms, you are the rockstar coder with minimal meetings booked in your calendar. You churn out code, good quality code of course. Any rubbish spaghetti code is considered “drawing aggro” and will probably piss off your resident healer and tank. I would naturally recommend fullstack developers for all 3 roles with specific focus/spec on API/backend, frontend/UI, and automation.
Healer/Sysadmin: In WoW terms, you heal the team members, but mostly the tank. You do little damage yourself but are fully capable of keeping the entire team alive throughout the instance. In software terms, you are the sysadmin. You deal with the technical debt directly produced by the team members. You try to ship their work even at times knowing that they are produced way passed their Ballmer’s peak. You try to tune and configure the software to keep it alive. You care about performance and high availability. A healer is arguably the most critical role in the team. You must be more devops than the rest of the devops boys and girls, if you get my drift.
This is absolutely true. Depending on the goal at hand, coming up with a functional governance model to work with 40 rockstars will be difficult. At a much larger scale, it is more about culture than anything else in my opinion. Your guild and guild master will be important, as their insight and coordination plays a critical role in the success. However, the fundamentals are the same. You still need small agile individual tribes or teams to perform certain tasks.
It is fairly obvious to see that you absolutely require a diverse and cross functional team. No single role alone can build a winning product, or get that epic win, even for Linus Torvald.
“I can’t do UI to save my life. I mean if I was stranded on an island and the only way to get off that island was to make a pretty UI, I’d die there.”
Linux Torvald, 13 April 2016 @ TED
At the end of the day, working together is the essence of devops. In the meantime, I had a great time writing this post 😀 Big it up to the Avengers, our residence craftsman guild.
❤ Cap-A
Avengers yo. #add2015 @savant_no @eggsdesign @Scelto_as pic.twitter.com/S6b3S018Ti
— Yves Hwang (@yveshwang) September 24, 2015
The road to ridding application monoliths is one wrought with many obstacles, mostly organisational. Whatever your reason behind this brave move, you have convinced yourself that you will fix this big ball of mud, somehow… You will no longer stand for this shanty town of a spaghetti code, riddled with nonsensical donkey poo. The code no longer speaks to you, it has surpassed the point of having a smell. This abomination has a cyclomatic “flavour” that you can almost taste it at the tip of the tongue. No amount of Ballmer’s peak is going to help. So you are going to make good on that promise to your linting tool, probably Sonar, for whom you have whispered hours of sweet nothings to the tunes of Bob Marley, “Don’t worry ‘bout a thing ’cause every little thing gonna be alright…” What once was a good idea has hideously mutated into a giant walking talking abomination that crawls under your skin and haunts your every step. Under the guise of some sound architectural decisions, you are going to pay down this technical debt, hard. You are going to to do microservice, and you are going to ship Docker containers. If this is you, read on.
Tasked with the daunting task of ripping apart functional applications into microservices, you will battle bikeshedders whilst debating your silly asses off with armies of monolith fandom. During what seems to be a very long coup d’état, this attempt to evangelise a newer leaner architecture and approach is riddled with skeptics. “What is frontend without JSF or JSP?! How dare you even question server-push technology like XYZFaces? Then how about the JNDI lookups and EJBs?! Surely you cannot replace these things?”
So six years ago, I had a very pleasant experience of pulling out Glassfish with embedded Jetty, replacing I-Hate-My-Faces with some simple JS (nowadays we call it the MEAN stack, or its many other permutations), and started building APIs with microservice principles. Turns out that is what Spotify did too at the time. So there you go haters. Bottom line, do not use J2EE no matter what if you care about having a competitive advantage. But if you need some good reasons, here are some:
Have a very clear idea of the different categories or lifecycles of the applications you are going to transform. Timing is important, as with showing results. Afterall, this is the minimum viable product (MVP) approach naturally. Highly recommend avoiding system of records to begin with, those are definitely not quick wins and you will be in an arduous match, going for the full 5 rounds. Your future competitive advantage does not sit in your ERP or CRM systems. If it does, then um, yeah.
The trend a few years back was relentlessly hating on Java and Java devs. Evidence shows otherwise. Java is still around and it is going to be around for quite some time to come. No need to switch out it just yet even after the programming nuclear winter imposed by object-orientation and Java/.NET alike. Good code, good ecosystem based on tooling, and good solid design patterns go a long way, regardless of application domain or programming languages.
The truth is the same could have been said about node.js. I recall a number of years back, few colleagues quoted Hacker News regarding the state of node.js and how immature it was and Java was the “preferred” choice, even though the sysadmin community bagged the crap out of Java at the time. If you make strategic decisions predominantly based on the whims of HN, then you are just as plonkers as the next troll. What your node.js/Java boys and girls need to remember:
So you have found a good set of business functional requirements to transform into a set of microservices. Heard of #lagom? Maybe Dropwizard or Springboot? The choices are probably all OK, and when doing microservices, there are simply no bad choices in my opinion. The gains outweigh the means here. The kicker is that there are probably a number of customised endpoint you will need to integrate with. This could be HTTP, something-else-over TCP or whatever. There could also be JPA or other nosql data stores you need to use. Pick your microservice framework component knowing that this is a framework and it can easily grow. The microservice strategy can easily bloat into “milliservice” or “services” (SOA?) if you are not careful. So just how do you stop the size of the code base from expanding? Keep distinct business functionalities as separate services and code bases. The sizing is up to you. Also, split up common functionalities into submodules. Both Dropwizard and Springboot has a bunch. Lagom for example has recently being introduced as the microservice framework for Java, it does have quite a lot of these connectors already in place. For me, I opted to homebrew our own microservice framework for maximum flexibility, ownership, and performance tuning.
Either way, armed with your chosen messiah of a framework, the idea here is to rain down free non-functional requirements across multiple projects and dev teams. Cost leadership for all!
Keeping your head above water is number one. Hang in there, the good days will come. Just remember, nothing is new in software since 1970, they just get modern marketing hype. And lastly, your fancy new microservice is legacy as soon as you launch. So please do consider the future generations. Let’s end this cycle of spaghetti monster code through old fashion craftsmanship.
something else 