A blog post on not having a blog

January 12th, 2022 No comments

I am a lurker in places like Hacker News. Today, someone submitted a blog post that resonated with me. This is nothing new, but it brought echoes of me feeling this sort of pressure that you need to have an outlet to show your smart thinking, your thought leadership, to the world at large, as if it cared. I have not written anything publicly in a long time, although I do lots of writing in my current job. Heck, I even don’t tend to my own personal website (I just realized that all the links I had on soup.io have gone as the website has basically changed its nature). I keep my site running but, to be honest, I cannot find the motivation to do some maintenance on it or even update my CV there (Is it really important to keep an updated pdf on a site hardly anyone visits? it seems we can survive just fine with LinkedIn).

Not that I have not done several attempts in the past, I have. I have a blog that has not seen fresh content in a long time. Years ago I took the time to write quite a number of answers in Quora and developed ideas and lengthy comments in LinkedIn posts and groups (perhaps some of those could be turned into posts with some additional work?). I keep a poetry blog too but the quality is probably not that good (not that I care in this case, it is just a small personal outlet) and inspiration does not hit regularly (I know, it has to find you working). Lately the well seems pretty dry, tho’.

Eventually, all these efforts lost steam sooner or later. One reason is the time and dedication required, and I guess some part is played by the social dynamics of places like Quora (could be just an excuse on my part). Regarding blogging, I am aware that everyone says how you need to keep at it regularly and with some degree of consistency, gradually improving and reaching out to more people in the niche you have chosen. I don’t have ambitions of a large audience or anything like that, but in any case I could not help but feel that whatever I could imagine to talk about, someone has, of course, discussed it before, better, in more detail and with smarter insights. The web is already full to the brim with drivel and regurgitated content. As in GitHub, forks of forks of forks with only minor differences in phrasing. I don’t think it needs any more of that.

Like the author of the post I linked at the beginning, why write about software architecture topics for example (ex-programmer here) if others have done it very well? I struggle to find a novel angle or a piece of valuable insight because, after all, many of us are doing work that is not that “amazing” from a technical point of view. I belong with the “great unwashed” that do not work on hyperscaled bleeding edge architectures in US West Coast MegaCorps (on the other hand I am sure the grass is not that green either in those places). I don’t like too much this idea either that you need to stick to a topic and just post all the time about that niche. I feel that to be quite boring, truth be told. I am quite interested in other topics, one example being geopolitics and Asian countries, or playing electric guitar, but these are not even my professional fields, I am not exposed to them on a daily basis, so what can I really hope to contribute that is novel in some way? Perhaps I am too influenced by the romanticized idea of the flaneur, the dilettante that dips their toes in many waters and and the Renaissance man that knows about many things, even when fully aware I will never be a polymath either.

Sometimes, however, I feel the pangs of remorse for not having an active blog with brilliant ideas, and that also happens with not having the GitHub profile that seems a must or with industry certifications (this is a topic for another moment).

I wonder if I should try something like Medium (is a change of platform a solution?). Everyone seems to be there already and probably that’s a good thing on the audience front, less so on how the web becomes more and more centralized, but I digress. Perhaps I should research what frameworks and what proven advice are out there in order to structure thought and produce better written word. I’d love to write something like this even if it is one post a year, at least it reflects an interesting life. I have tried to generate crazy list of ideas like James Altucher says, and I can conjure a few, but it takes time to develop these ideas into something worthwhile, and frankly, most are crap. Developing them takes time, and that takes smart. Perhaps I could do the exercise of writing small reviews of books I have read, which I’ve done in the past anyway, and keep that as a habit. Perhaps the simplest thing that works best is to commit to a focused hour of writing every week. What are other ideas? What has worked for you?

Or it can perfectly be the case that I am not that smart. That would be ok too. The world also needs common people I guess. The reason I am a lurker in Hacker News is that I am so out of the water in most discussions that I can only try and learn something. I don’t know what I don’t know, but I know there is awful lots of that.

By the way, I could never decide on whether Mr. Altucher is more of a very smart guy or more of a charlatan.

Categories: Uncategorized Tags:

Some notes on Mark Weiser’s Calm Technology.

September 26th, 2019 No comments

Just yesterday I heard about Mark Weiser for the first time. He is considered to be the father of ubiquitous computing, and he had a very interesting vision of how technology should behave and should help or enhance us. We could say we are now almost immersed in said ubiquity, but from his main tenets, I think we are immersed in an at least partially wrong kind of ubiquity.


These tenets are:


  • The purpose of a computer is to help you do something else. We sure pretty much agree on this one, at least on principle, but how many out there basically use their computer almost the same way they use their tv sets? that is, to escape life, not to help them achieve something better.
  • The more you can do by intuition the smarter you are; the computer should extend your unconscious. Now, this would be the real thing. Indeed we already enjoy a crude form of that, by constantly checking the web for facts and figures, missing some sort of direct brain search capabilities, which as of now remains in the realm of sci-fi.
  • The best computer is a quiet, invisible servant. Now, this is were we can see how things have gone awry. It’s more like we far too often are  servant to our devices via the constant attention they demand from us.
  • Technology should create calm. This is an important point, as our digital personas, constantly online, most of the time via several devices concurrently, seem to be more prone to anxiety and stress and shortened attention spans than to calm due to the constant alerts, notifications, vibrations and all manners of data snippets that snap at us all the time. I hardly see anybody that is actually calmer once submerged in this flow.

This idea of calm technology is organized around the concepts of center vs periphery (our peripheral reach):

What is in the periphery at one moment may in the next moment come to be at the center of our attention and so be crucial. The same physical form may even have elements in both the center and periphery. A calm technology will move easily from the periphery of our attention, to the center, and back. This is fundamentally encalming, for two reasons. First, by placing things in the periphery we are able to attune to many more things than we could if everything had to be at the center. Things in the periphery are attuned to by the large portion of our brains devoted to peripheral (sensory) processing. Thus the periphery is informing without overburdening. Second, by recentering something formerly in the periphery we take control of it” (this quote is from Amber Case’s book with precisely the title Calm Technology)


Warp descent

These are key observations, for much of the technology and digital products created today aim at being central all the time (this way lay monetization) which reduces our attentional capabilities and produces overburden. To row against that tide we need to make a deliberate effort if we are to avoid the information to take control of us instead of the other way around, and avoid technology creating stress instead of calm. There is “systemic friction” with overburdening and interrupting information.

The challenge seems evident then, how to design technology that respects our attention, not only that but ideally that it also help us improve our cognitive capabilities. This is not what we have now, even there are tools and workarounds to help safeguard our attention, the whole environment is not propitious, it is in fact geared against that, and requires users’ deliberate action or quite some settings tweaking, which is another way of us tendering to tech, and not tech being designed with our calmness in mind.

I am not an UX expert, so these lines are basically a serving of food for thought to try and think how we could build on calm principles and calm communcation patterns. Or how this idea of calmness could be applied not only  to the software and digital products we design, but also to teams and companies. That’d could have a real impact for the better for people and probably for some of our current social problems as well.

This reminded me of the slow food idea, and it seems this could be labelled as “slow tech”. Furthermore, could we imagine tech one day being as ubiquitous but also unobstrusive as the electricty we have at home? much of our current technology breaks without warning, or interrupts us with status or software updates, taking us out of our flow and away from our goals, and that basically lays to waste Weiser’s tenets enumerated at the top.

You can read the original paper here

Categories: rants Tags: , , , , ,

Never split the difference, brief book review

November 19th, 2017 No comments

A few days ago I finished reading “Never split the difference“, by Chris Voss. I of course don’t claim to be an expert at all in negotiation, but this is a great book. Although the author has an extensive background in hostage situations, kidnappings, etc. the advice and lessons in the book are no doubt very apt to be applied in all areas of life, whether in the workplace or also on one’s personal and family life. It borrows quite a lot from behavioral and neuro science areas without getting geek or scholarly, which is why it applies to almost any situation. In fact, it is not only a book on negotiation, you could say it is a very good sales book.

I almost don’t want to other people to read it and keep that competitive edge for myself that being said, of course gaining that edge require practicing the skills mentioned a lot, especially for real time execution.

A reader took the trouble to actually write down their notes on this list which basically gives you a very good view of the distilled advice in the book. It is, in fact, a very good idea to do this with book notes. I tend to write a lot on books, but this keeps the notes handy, more actionable and more easily reviewed when you don’t have the book at hand, which is quite often. I commit to do this myself for the best books I read.


Categories: books Tags:

Review of Exponential Organizations

June 27th, 2017 No comments

Cover of Exponential Organizations

Some say that the Singularity University is science fiction expensively packaged for execs, but even if one always needs to take grandiose claims and hyped inventions-to-be (or never-to-be) with a grain of salt and some skepticism, this is still a book anybody with an interest in innovation and technology should read. It is an enjoyable read and there is plenty of good ideas in the book, although these are not fleshed out in enought detail to make them actionable advice.

One of the most important points is the Massive Transformative Purpose (MTP), which is more than a vision or mission statement. This core idea has to be stated clearly in few words, but it has to be compelling enough to inspire the initial people, smart enough to nurture a community as it grows, and audacious enough to give plenty of room for growth.

Other key points from the book are the notions of SCALE and IDEAS:

S: staff on demand
C: community & crowd
A: algorithms
L: leveraged assets
E: engagement

I: interfaces
D: dashboards
E: experimentation
A: autonomy
S: social technologies

As a somewhat negative point, it necessarily has to take from the same examples as everyone else ( Uber, AirB&B, Twitter, GitHub, Local Motors, SnapChat, FaceBook etc) and in that sense it is too mainstream. It would have been nice to look at minor players making an impact in more significant areas, because, honestly, SnapChat does not really have an MTP.

If you like the Lean Start up approach, this book looks at some of the same ideas. It has some really interesting insights into how larger organisations can create, invest in, develop businesses that are free to grow and change without the constraints of the larger parent company. Gives great rules/guidelines for how to setup a business that could grow quickly, not so much from an actionable advice angle, but more from the inspirational outlook and the potential of great bold ideas.

My own copy is heavily underlined and annotated, but I leave here a list of quotes other readers have taken the trouble to put together in a list.


Categories: Uncategorized Tags:

arquitecturas escalables e invisibles

June 14th, 2016 No comments

AWS Lambda, Azure Functions, Google Cloud Functions, OpenWhisk from IBM … el mundo “serverless” se nos viene encima con todo el furor de un hype en celo … la opción de ejecutar código sin provisionar nada, meras “funciones” expuestas en internet. ¿Va a seguir el servidor de aplicaciones el mismo rumbo a la obsolescencia que el famoso mando intermedio? ¿Irá detrás el servidor web? No en vano el technology radar de abril del 2016 de ThoughtWorks dice que precaución con el servidor de aplicaciones (“hold“, como lo clasifican ellos) como pieza clave del ecosistema. Como siempre, depende y las cosas y las organizaciones varían mucho en su adopción o su pereza (los “laggards”). Pensemos también, por otra parte, en la extensión de las beneficiosas consecuencias – a priori – para temas de seguridad, patching, gestión, etc (¿malware si no hay servidor?). Otra vuelta de tuerca en la idea de correr cosas virtuales sobre cosas virtuales sobre cosas virtuales (“it´s virtual machines all the way down”).

A pesar de que la idea es vendida como si se pudieran simplemente “colgar” funciones independientes en la nube – ¿y en realidad no deja de ser un servicio web justo eso? – al final los proveedores lo que hacen es envolver esas funciones en una API gateway y exponerlas para que los clientes las llamen mediante el popular REST. Esto se apoya en que tiene que haber un entorno de ejecución, un contenedor con la máquina virtual (me refiero a la maquina virtual de Java por ejemplo, no a una maquina virtual en su otra concepción). La ventaja es tener ahora algo más ligero que un OS para poder correr una VM para poder correr una lambda, optando por apoyarse en un contenedor que tiene lo justo y necesario, o corriendo directamente sobre el hypervisor.

Citando de la pagina de AWS Lambda “the core components are Lambda functions and event sources. An event source is the AWS service or custom application that publishes events, and a Lambda function is the custom code that processes the events.” Esto me sugiere arquitecturas reactivas, observables, incluso eliminar ese viejo ESB… escenarios de integración y transformación de datos. Sugiere también sistemas difíciles de depurar, difíciles de entender y de razonar sobre ellos, como contrapartida. Sugiere programación funcional y construir sistemas enteros en este paradigma, combinándolo con un uso juicioso de CDNs. Desde luego, potencialmente puede significar muchos cambios a nivel de arquitectura de soluciones. Hay gente construyendo sistemas enteros con piezas (¿de lego?) como Auth0, Firebase, API Gateway, Lambda, SQS, S3, CloudSearch, Elastic Transcoder, etc.

robust profits

Evidentemente, no es que los servidores realmente desparezcan, sino que más bien desaparecen como preocupacion del desarrollador: problemas como despliegues, escalado, configuracion e incluso el propio sistema operativo se nublan en el olvido, mientras nos centramos en servicios y plataformas elasticas de computacion. La teoria dice que ahora es aun más facil construir sistemas complejos que pueden crecer, escalar, evolucionar a medida – el clásico sales pitch, que ya sabemos que no es tan sencillo ni tan bonito todo.

Para saber más:

Comparativa entre AWS Lambda y Azure Functions

ThoughtWorks sobre Serverless Architecture

What is serverless

entrada sobre Serverless en CloudAcademy

reflexiones sobre el rol de arquitecto…

March 14th, 2016 No comments

Entre las “recriminaciones” que son cliché habitual acerca de los arquitectos y su rol, además del síndrome de la torre de marfil, es habitual oír quejas acerca de esa tendencia entre a querer abandonar los proyectos una vez que la parte digamos “interesante” de los mismos está finalizada o a punto de finalizar (¿instinto de supervivencia? 😉 ). Es decir, que una vez que se ha planificado la arquitectura, se han agotado todos las excusas para asistir a infinitas reuniones y desayunos de trabajo, los viajes y se han planificado las ejecuciones y todo parece perfecto sobre el papel, lo famosos arquitectos desaparecen.  En realidad, no sé si realmente existen estas figuras mitológicas tal cual hoy día, tal vez antaño, pero yo no las he visto, aunque si he visto gente con los pies muy lejos de la tierra en todo tipo de posiciones.  No creo que sea solo culpa del ser humano individual (si bien es muy cierto eso de que “everyone wants to design, nobody wants to maintain”…), sino también de las organizaciones, que al fin y al cabo son construcciones colectivas.


Hay otra forma de ver las cosas: el arquitecto debería ser el propietario “end-to-end” de la solución.  Es más, este rol ni siquiera es algo fijo sino que debería cambiar o evolucionar en consonancia con las distintas fases del ciclo de vida del proyecto.  Creo que esto no se reivindica o se resalta suficientemente, tanto para unos como para otros. Teóricamente, nadie mejor que el arquitecto debería conocer la solución mejor.  A nada que uno haya estado en esta industria suficiente tiempo, se dará cuenta que poco o nada tienen que ver el papel y esos archivos .vsx iniciales con la implementación real del sistema al final de la “larga marcha”, y lo que parece muy completo y casi “perfecto” en los powerpoints – que lo soportan todo -, no tiene nada que ver con la realidad ( que básicamente es lo mismo que les suele pasar a esos ejercicios de wishful thinking que son los Gantt, especialmente en el caso flagrante de aquellos creados antes de tener claros los requisitos, ni de haber tirado una línea de código, los Gantt “promesa política” que los llamo yo, pero ese es tema para otro post ).  Al igual que ocurre con los dichosos Gantt que tanto daño han causado, es fútil pretender que se puedan conocer de antemano todas las circunstancias cambiantes, errores, problemas, asunciones y premisas que cambian y todo tipo de factores imposibles de anticipar, porque al final se trata de sistemas “vivos” (creo que los matices en “live” lo expresan mejor).


Debido a todo esto, es imprescindible que el arquitecto continúe en el proyecto – al menos en un rol de supervisión y liderazgo técnico dando soporte al equipo y a negocio -, hasta incluso durante la fase de entrega, donde sigue teniendo un rol importante.  No basta con ser un arquitecto en su torre de marfil, y se debe revalidar el papel del “coding architect” que conoce también la implementación de su solución y los requisitos de infraestructura, y como dar soporte a los requisitos no funcionales elicitados.  Ciertamente, hoy día se ha desgranado o especializado tanto el papel del arquitecto que el termino corre grave peligro de no significar nada, o de significar cualquier cosa, y dependiendo de la empresa tenemos simultáneamente cualquier combinación de data architect, business architect, integration architect, Infrastructure architect, solutions architect, Enterprise architect, information architect, delivery architect, UX architect, etc. etc.)

Data science

Al hilo de esto lo cierto es que tal vez el rol del arquitecto sea tan difícil de definir porque las habilidades y tareas del rol van cambiando según el proyecto va agotando fases en su imparable carrera hacia el <sarcasmo>más fulgurante éxito, directo al cuadrante mágico</sarcasmo>. Por lo que me toca más cercano, es fácil ver como el solutions architect debe irse convirtiendo en un delivery architect (podríamos decir arquitectos de entrega o algo así, pero queda fatal). Esto al final, no es más que insistir en el principio de responsabilidad (responsibility and accountability) y de propiedad (ownership –  a veces los vocablos ingleses parecen transmitir mejor la carga semántica).  Al principio será más el responsable de entender bien los requisitos, coordinarse con los stakeholders de negocio (son diferentes skills, como vemos, tanto técnicos como sociales) y entender los limites tecnicos, presupuestarios, manejar expectativas, el entorno político y cultural, y dar lo que parezca la mejor opción, a su juicio y con los datos disponibles.  Sin embargo, nada – y nunca mejor dicho lo de “nada” – acaba con la entrega de un montón de documentos, de entregables definidos por nuestro framework de arquitectura preferido.


El aspecto clave durante la vida del proyecto es la gestión técnica, alejándose de esos arquitectos extremófilos acostumbrados al aire enrarecido de la sala de juntas, donde de nuevo tenemos capacidades muy diversas que aportar: gestión de stakeholders y/o grupos de interés, gestión de deuda y riesgos técnicos, calidad, metodologías, gestión de equipos, “fit-for-purpose”, gobernanza y, sobre todo, asegurarse de que la solución no se desvía del alineamiento con la arquitectura empresarial y los objetivos tácticos o estratégicos a los que debe su existencia.


Aquí es donde probablemente la línea entre Solutions Architect y Delivery Manager se solapa mucho, y podemos hablar de otro rol más, el de Delivery Architect, y es que el delivery manager raramente tendrá el mismo conocimiento que el arquitecto de una solución específica, ya que éste es el propietario de la solución completa, por tanto es de suponer que el arquitecto sería el que tiene la mejor y más completa visión y el conocimiento sin el cual, el Delivery Manager tendría muy difícil ser capaz de cumplir con sus responsabilidades correctamente.  A menudo el factor decisivo en el éxito o no de un proyecto será la colaboración eficiente entre el Delivery Manager y el arquitecto, no la calidad sobre el papel, no la belleza del diseño de la solución en unos cuantos visio o UMLs. El arquitecto debe por tanto ayudar en todo al Delivery Manager para que se tomen las mejores decisiones. En esto el arquitecto pasa a ser un delivery architect. Su rol va – y debe hacerlo – mutando según evoluciona el proyecto. Esta figura que llamamos el delivery architect también debe de no perder de vista el foco en los requisitos no funcionales. No solo se trata de definirlos – que también – sino de asegurarse que el Sistema o la solución propuestas y desarrolladas se adhieren a dichos requisitos. No olvidemos que al final se trata de que la arquitectura de soluciones realizada sea operable y efectiva desde el punto de vista del coste y de las estrategias definidas a nivel empresarial.

A riesgo de sonar muy pomposo, cierro con una cita de un libro que no he leído

Se audaz y astuto en tus planes, firme y perseverante en su ejecución, decidido en encontrar su glorioso final.

Carl von Clausewitz, De la guerra 



Speed of understanding

December 4th, 2015 No comments

Is your code easy to understand, can someone new to the codebase grasp quickly most of the intent of the code? What is the speed of understanding of your code.While this is basically the old idea that code should be readable by humans – that includes business people and managers 😉 -, what strategies and tactics can you put in place to gain speed of understanding as an intrinsic quality in your codebase?The thing is that very rarely someone who actually wrote the code is the one that will also maintain for the entire lifetime of the software (and, well, even in that case, knowledge about a codebase is one of the most ephemeral things in life, especially in the case of significant – read, large – codebases).

When a codebase is not so well organized, it very quickly becomes so confusing that even the original team members find themselves scrambling and frantically searching through the codebase in order to find that snippet they wanted to reuse, that pesky function the name of which they can’t recall ( for some reason, some pieces of code or some function names are much harder to commit to memory and find quickly. Treat that as a warning that some action is needed there!).I assume that we are naturally working in a OOP environment, which probably lends itself best, although of course functional languages and strange beasts like javascript can do the trick as well.Two of the strategies (or tactics maybe) that help the most are:


  • Use of DDD, a well codified plain-object domain that models / reflects your business, which is how DDD goes about creating a shared vocabulary between business and engineering. That will lead you to having a DSL for the business domain.
  • Write the client code first – the client code that you would like to have to write. This scenario is greatly enabled by having some DSL first, and, of course, hindered by not having that DSL in place. This is similar to using TDD in what some call “outside in” TDD.


These are for me strategies, more that mere tactics. Both are supported of course by TDD, as you can actually use TDD as a “discovery” too for that client code you want to be writing. However, I am willing to bet that if you have non-trivial business knowledge about your domain already, you can skip that process of discovery and write the code you want to see (as in “be the change you want to see”, you know ), without that meaning “do not back up your code with tests.”  That being said,  it is easier said than done of course.


governance frameworks


Now, there are tactics as well. Nothing trailblazing here:


  • Excellent naming conventions and the discipline to uphold them. It’s already a distant past when one had to save precious bytes by being skimpy on names. Not anymore. Probably only in the case of lambdas, pattern matching, etc. should you be getting away with names like, x, _, temp, and so on.
  • Good commenting habits (there is a lot on this in that great book – Code Complete)
  • Refactoring to small single-purpose functions.
  • Do not overdo the “look ma how smart I am”. Sometimes, they say write code that is not “so smart” (clever one-liners just because I can, nested ternary operators, complicated lambdas), and while that is true to the extent that you don’t want to write production code like this or this, that does not mean you do not take advantage of (relatively) “advanced” features in your language, for fear that other developers coming in later are not familiar with those. They might never learn those!
  • Consistent style in all things: naming, spaces, indenting.
  • Share the code. Have other developers from other teams have a look. Even ask a lay person, your boss for example, to guess what a piece of code does.


You need to use the strategies underpinned by the tactics to achieve that speed of understanding.Would there be a way to actually measure that quality of speed of understanding? I am not that smart to figure that out. Probably not in an absolute way, as there are different styles and preferences for programming – some like fluent api style, others call it the train wreck, for example.For the time being maybe, it’s enough that you always keep that purpose in the back of your mind when coding, until it becomes a habit.
Let me have this as one purpose of mindfulness in coding from now on. Let’s be more aware of this when designing and coding.

Categories: coding, rants Tags: , ,

More stuff on microservices, this time for the .net world

July 15th, 2015 No comments

What factors are important for microservices? (a.k.a. fine-grained SOA). It’s said that Node.js is an excellent fit for a microservices approach – which lends itself very well to the fashionable container approach – as it has the following:

  • Excellent package system (npm)
  • Minimal effort to publish new packages (package.json)
  • Node.js itself encourages lightweight, narrow-focus services, not big monolith-ish services
  • Designed to be async I/O in order to achieve better scalability
  • End-to-end javascript stack

This is all very true, and we can add ease of “containerization” of those services.  What about those of us who work in the .net world? For years, the perception that the .net world was somewhat behind in certain aspects, such as DDD adoption (or the blissful ignorance of it), microservices, containers (which are coming soon in windows) and so on. However, I think the tooling is improving a lot this year and sweeping changes are coming to the platform with the advent of .net core, the new runtimes, etc. Well, we can have all of this, although we might have to make more of a conscious effort to steer our development practices and inertia towards a more similar approach.

  • We have a good package system, nuget, and we also have chocolatey (check out the difference). You can even implement your own nuget feed.
  • So that means you could bundle certain things in packages (for example, implement cross-layer concerns, AOP stuff, etc. in nuget packages) and then add them to your nimbler solutions
  • The new VS2015 brings great improvements to the web project idea, doing away with the classic solution approach we are so familiar with and taking the .net developer to the folder-based solution structure, as we are used to see in many other languages. With this, there comes semantic versioning, and json files for handling dependencies, the ability to bring grunt.js and gulp.js on board, introduce better minification and uglification into the build process, and so on, so in this sense the .net developer has been brought into the same arena as developers in the .js world.
  • Use Web API or REST-ful traditional WCF web services – if you have such legacy services, they can be restified easily (pdf)-, or NancyFX, or ServiceStack
  • You can have async as well, of course

So it’s perfectly possible to get the same approach (except the full-stack thing). You can dockerize too those services, if you want. This way you achieve this same “component”-oriented architecture. Don’t miss the “Docker for .net developers” Channel 9 (by Dan Fernandez) series if you want to gain a clearer picture of how Docker and .net applications fit together.Naturally, you get the same drawbacks:

  • Deployments get more complicated. No need to argue that a monolithic application could be easier to deploy, although often those deployments are riddled with fears as well. At the same time though, error surface in deployments gets reduced, or more scoped, in the sense that if only one service is causing errors, at least you know where to look, and scope is not as big as in a monolithic application.
  • As deployments get more complicated, you certainly need to automate testing and deployment, so depending on your current practices, or skill sets, this might be possible, or downright impossible if a previous effort to bring operations up to date is not done first. So, many companies will find themselves not to be in the right position for this point and the previous one. Especially if there is no culture of DevOps.
  • Operations get more complex, hosting, managing, lifecycles, monitoring more systems, more processes, more logs (integrated views needed here) etc.
  • Need to consider messaging patterns, need to consider how to handle transactions, if at all, or compensating them, need to consider how to test processes spanning several services that interact together.
  • Need to consider sharding and partitioning your database. After all, what use is deploying redundant copies of your services if they’re all going to be talking to the same database?  You get a potential bottleneck and a dangerous weakest link in your system. If using databases such as mongoDB, you need to have replica sets, or similar mechanisms in other systems.

Significant challenges lie ahead. Probably it’s safe to assume that not everything is quite mature in this confluence space between microservices, containers, and the usual, and not so easy, concerns of scaling, replication, hosting, clustering, service discovery inside containers, resource and performance (cpu, ram, disk etc) and so on and so forth. Kubernetes is something to watch closely in the near future, now that we can run on Linux too.  Containers can have their own security issues, especially if you download images you’re not 100% sure about their provenance.Dealing with failed services / containers.  I think that bringing some of the strategies the actor model proposes in the face of errors could be interesting. After all, in a way one can imagine containers to be somewhat like actors, they’re cheap, lightweight (actors are better in this sense), easy to start or to kill which brings me to the point where maybe considering a pure actor model (akka.net -ported from classic Akka- or even Microsoft Orleans) could be a better option. You can have millions of them, ready to work for you behind your API gateways. I think that could be a nice idea, or at least it looks very nice on paper. Surely it is not so easy to implement as it is to dream it.  Certainly we’re in for a big sea change 🙂

final state of new features in C#6

July 14th, 2015 No comments

Ok, this topic has already been blogged to death, so my 2 cts flogging a dead horse here. From earlier posts reporting the new features back in 2014, some of the features have been dropped, and others have changed their syntax. So below, I add some gists detailing the most salient features in the new version of the language coming with VS 2015. I will pass on explaining each one, since a) the examples are easy to understand and b) there’s plenty of further explanation in the web and I am too lazy to replicate that. Automatic property initializers Self-explanatory here, I think.

Using static
String Interpolation Access properties directly in the string template, instead of the old tired way with the ordinal placeholders. Cleaner syntax and less prone to errors of placement and order. Notice the $.

Null comparison operator This is really a welcome change, instead of polluting code with null checks or implementing extension methods to avoid that. Now you can check for null references and null properties in a much cleaner and more natural way:
Inline Event Handlers

Exception filters This is a welcome change as well, for cleaner management of exceptions. You might have seen this is a previous syntax with if instead of when.
nameof Although this could be emulated before, it is nice to have this and avoid hardcoding parameter names.

Expression-bodied members
Awaitable catch and finallyThis works as well for finally blocks. New way of initializing dictionaries
And now, the stuff that has been dropped Stuff that has been dropped IEnumerable params This does not compile:

Declaration Expressions

Categories: c# Tags:

we don’t really have a strategy

June 12th, 2015 No comments

It is said a strategy has to have these components:

    • Purpose
    • Plan
    • Doable series of actions
    • Measurable goal(s)
    • A narrative

To this, I’d add that it is important as well to weight side effects as well as the validity of those goals. It could well be that a strategy could be beneficial in the short term, and disastrous in the long term, or cause a lot more damage to third parties (therefore, it is externalized and seems much less important) than the benefit it may bring.

Let me call them “risks” in a generic way. So a strategy must be iterative and open to revision at all times, if unforeseen results appear from those goals. Don’t fall for the trap of naive rationalization or the belief – wildly spread in politics today – of omniscience and infallibility.  Most often, I think we do not know how to do strategy.  And that probably we even can’t. It’s an illusion.

In both the business and the politics worlds, two elements are magnified and the important – and hard – stuff, neglected. We love simplified narratives with clear – albeit fallacious – causal relations, and we love the apparent purpose we made up in our heads – that is, we are focusing on the fairy-tale results, the dreamy end, the wishy-washy grand statements, and we want to obviate the hard part, which is designing your plan, deciding what work and efforts are needed, also to realistically assess if it’s doable at all in your context and then decide how you will measure success (or the lack thereof, in order to learn).

Assessment and measurement are to be done with metrics and numbers. These are notoriously and largely absent from political manifest and party programs for example – and nobody seems to be shocked by that glaring omission -, which are the perfect showcase of how the public at large prefers to focus on the narrative, the seduction part, and forget about the hard part (as bold as unsubstantiated slogans or mission statements as “reclaim the city for the citizens”, “build a fairer more egalitarian society”, for example), and that is probably because politics is not only the art of the possible, but is as well about deceiving and seducing in order to nudge oneself and one own’s clique into a rent-seeking position of power.

But the business world is also full of grand purposes, transformation projects and strategies (a lot of them digital, these days) that remain just that, dreams and a lot of meetings.  A strategy should inspire, yes, but before that, you need to perspire and work hard to come up with one.  One that is backed by cold hard facts, by sensible reasoning and assessment, by taking into account what worked and failed in the past as well.  It does not have to be something very complicated. Something like this is probably enough to get started.

NARRATIVE Developing business CRUD applications for our clients can be very fun!
PURPOSE Position our company as a top software development boutique
PLAN Rather than rely on price-based race to the bottom competition, compete on quality and real value
ACTIONS Invest in quality training in bleeding-edge technology
Partner with great companies
and/or open source projects
position ourselves in the radar by writing blogs
speaking at conferences
publishing books or papers
MEASURABLE GOALS Are we getting more contracts?
Are we working with companies perceived to be leaders? what are your desired partners?
Have we moved into or towards thought-leader territory? if yes, how can you prove it?
Have we been able to raise fees and improve profit in projects? How much?
Are we delivering better and faster? Percentages, please?
RISKS Hard work is more prone to quitting
Complacency and relax
Harder to maintain momentum

I just came up with this in the time it takes to actually write it, so please excuse the simplicity, but I guess you have seen plenty of documents full of the three first points, and not so many of the other three, especially the last two.

Without those, a strategy is worthless.

Categories: rants, strategy Tags: ,