They're both widely used, subsets of JavaScripts, high performing and yet... they're technically different. But different in what way, more precisely? In a “React.js vs Node.js” comparison, which framework would turn out to be the best choice for building your web application with?
And why?
Some might say that comparing the 2 JavaScript frameworks would be like outlining the differences between a high-speed train and a... sports car. They're completely different things.
And yet, since both Node.js and ReacJS are temptingly advanced and equally popular among web developers, you can't help asking yourself:
“Which one should I use for my next JavaScript project?”
And the answer must be hiding in precisely those key differences that set apart the 2 equally efficient and equally tempting frameworks.
So, let's dig in for these differences so that you can set them against your own project's:
various parameters
size
dependency ecosystem
maturity
… and against your specific business needs, as well, so you can identify for yourself which one's the best choice for your custom web app:
1. React.js: What Is It Used For?
But let's start with what React.js is before we dig into its use cases:
It's an open-source JavaScript library (rather than a “conventional” web framework) that one can use with the web browser.
One used mainly for:
building web browser apps (and not for executing them, like it's the case with Node.js)
building high-performing, dynamic libraries
building great user interfaces perfectly equipped to render large datasets
2. Why Would YOU Use React.js? Why Choose It Over Node.js?
Let's fast forward to that moment where you will have already made your “React.js vs Node.js” comparison.
Now, after seeing each JavaScript framework's pros and cons, why would you opt for React?
The benefits of React boil down to... 3 essential ones:
2.1. It's SEO-Friendly
And it's pretty predictable that ReactJS is SEO-effective if you come to think of it:
Compared to other JavaScript frameworks, ReactJS renders code from the server right to the browser, as a regular web page.
So, we can no longer be talking about Google (or other browsers) struggling to read your JavaScript-heavy web app.
2.2. It Performs Better
No wonder: it creates its own virtual DOM, after all.
How does this impact your React web app's performance?
DOM loads only a part of the web page (compared to the traditional full-refresh model)
React handles all the regular updates in the DOM
2.3. It Embraces a Component-Based Architecture
Another one of React's biggest “selling points” is its fully component-based architecture:
You get to create your own components and display, combine, reuse, import and integrate them into your core content as needed.
And there's more. More key reasons why you'd want to choose React.js over Node.js:
with React you can reuse code
it ships with smooth interface designs
it updates faster
it is view oriented
it provides support both for the client-side and the server-side
it's easier for you to write UI test cases
it allows you to write less code
3. And Why Would You Be Skeptical of Using React.js?
For React.js must have its own limitations and shortcomings that might discourage you from using it in your project. And determine you to go with one of its “rivaling” JS frameworks instead...
Here are some of its off-putting disadvantages:
a steep learning curve
Flux architecture
a discouragingly sophisticated view layer
it uses JSX, a mix of JavaScript and HTML
it's a JavaScript library, not a framework
you might still be required to perform some configurations if you need to incorporate it into an MVC framework
4. What Is Node.js?
“Is React the same as Node?” you might ask yourself.
But to answer that you first need to define Node.js, right?
It's a lightweight and efficient JavaScript runtime environment on the server side, powered by the Chrome V8 JavaScript engine, that uses a non-blocking I/O model.
Its event-driven model enables you to create fast and scalable network applications.
In this respect, the callback concept that it uses enables Node.js to tap into an event-driven single-threaded server and to execute JS on the server-side.
5. React.js vs Node.js: Main Reasons Why You Would Want to Use Node.js
What are the key benefits of using Node.js for developing your web application?
Again, as in the case of React.js, I'll boil them down to 3 major reasons why you'd be tempted to choose Node.js:
3.1. It Ships with Its Own Package Manager
And this benefit becomes even more significant if you think of Node.js's ecosystem of thousands of package modules.
Having a dedicated CLI at your disposal, to access and install all the packages that you might need during your app's development process, is a true time-saving tool.
3.2. It Can Be Used as a Server-Side Proxy
Try to imagine these 2 common scenarios:
You need to retreive data from various multiple sources or to proxy multiple services with different response times.
How do you do that? You simply use Node.js as a server-side proxy.
This way, your web application's equipped to handle multiple, simultaneous connections efficiently.
3.3. It Manages Large Streams of Data
Being designed to read really large datasets is one of Node's major advantages over React.js.
And of particular importance to you if that networking application that you're building is expected to handle wmassive loads of data and files in real-time.
In this respect, Node.js “joggles with” streams of data:
It treats HTTP requests and responses as data streams (instead of isolated events, like in the buffering model).
This way, it calls multiple data sources simultaneously. A great feature for real-time video streaming, for instance, where your app would be challenged to stream really large files.
And these are not all the reasons why you might consider it to be the right choice for your JavaScript project:
it shares the same code on the client and on the server-side
it's highly extensible
it enables you to write real-time, server-side applications in JavaScript
6. Node.js: Limitations and Drawbacks
And it would be only fair to outline some of Node.js's shortcomings, as well, right?
So, what could be the main reasons why you might not find it suitable for your next web application project?
its nested callbacks
it's doesn't handle CPU-intensive tasks efficiently enough
new and new APIs get released, so you need to be on a constant alert for backward-incompatible changes
it's suited for web servers only
it challenges you to troubleshoot relational database issues
The END!
Now, what's the verdict? In a React.js vs Node.js confrontation, which JavaScript “framework” checks off most of the goals on your project's list?
Image by Andrew Becks from Pixabay
RADU SIMILEANU / Aug 01'2019
What is a cloud-native application in the context of cloud computing? Does “cloud-based” and “cloud-native” refer to the very same type of architecture?
Does cloud-native development mean using a specific set of methodologies and tools or simply hosting, running and managing your app in a specific environment?
Let's try to define, in plain English:
what cloud-native apps are
the key principles of the cloud-native development process
… and to bust some of the myths and confusions around cloud-native technologies and the cloud-native type of app architecture.
1. “Cloud-Native”: What It Means & Key Patterns
A cloud-native technology enables you to build and to run your scalable app in a dynamic environment: a public, private or hybrid cloud.
To give you just a few examples of specific techniques supporting the “cloud-native” approach: immutable infrastructure, containers, service meshes, declarative APIs.
What they do precisely is enable loosely coupled systems. This way, you get to ship new features faster, with less effort, more predictably and with zero impact on the end user's experience.
2. What Is a Cloud-Native Application in Plain Words?
The most concise definition possible would be:
It's an application developped using cloud-based technologies, fully hosted and managed in the cloud.
Do you sense the underlying difference between a “cloud-based” and a “cloud-native” application?
While the first one might be an older app re-architected to run properly on a cloud operating system, the second one has been hosted in the cloud from the very beginning.
It runs in cloud end-to-end...
Meaning that it has been written, tested and deployed in the cloud, using technologies and services that are cloud-based and not just rehosted, subsequently, to a cloud computing environment. That opposed to the (just) cloud application.
Now, if we were to highlight the traits that set them apart from traditional applications, I would sum them up to 3:
they're built with agility and high flexibility in mind, which translates into better security, top performance, and improved customer experience
… and into the high speed at which you can run new features, apply changes and, overall, customize your app
there's no monolithic software codebase that they depend on; instead, they're built in a modular manner, leveraging multiple infrastructures and cloud computing frameworks
3. 3 Defining Characteristics of a Cloud-Native App
“What is a cloud-native application?” is a question that calls for another one:
“What are its definining features?”
In other words, how can you identify a cloud-native application?
Let me trim down the long list of traits to the most specific ones:
they're not limited to certain public cloud infrastructures
they scale better since they tap into the cloud platform's elasticity
they're built using a set of cloud-specific DevOps methodologies, technologies, and architectural approaches: lightweight container environments, infrastructure as code, microservices, orchestration
4. Why Would You Develop a Cloud-Native App? 7 Main Reasons
If you think that the above-mentioned characteristics don't stand as strong enough reasons for you to opt for cloud-native development, here are some more convincing ones:
4.1. Managing Your Infrastructure Gets Easier
Let the serverless handle it for you!
With serverless platforms like AWS Lambda and Azure Functions, operations like configuring your networking, provisioning cloud instances and making sure there's enough storage will get automatically taken care of.
All there's left for you to do is upload your code as functions...
4.2. Cloud-Native Apps Are Resilient to Failures
“What is a cloud-native application?” It's that “ideal” app that ships with built-in self-healing.
Therefore, expect it to handle outages automatically, to be inherently fault-tolerant. If trouble strikes, you cloud-native app processing will move from one data center to another promptly and discreetly.
In short: the end user's experience won't get affected and you don't need to worry about downtime costs.
4.3. You Can Release Your Apps Faster
Since it supports DevOps processes — streamlining key operations like build, test, deployment automation and collaboration — your cloud-native app will speed up the whole software delivery process.
4.4. Lower Costs
And the 4 key reasons behind the inevitable reduction of costs are:
containers: containerizing your app will enable you to manage it easier and safer
cloud-native tools, which lead to a certain standardization of the tooling
the open-source model
the serverless computing, which supports a pay-per-use model and enhances flexibility in pricing
4.5. Your App Scales Automatically to Accommodate Your Growing Needs
One of the main attributes of a cloud-native app's architecture is auto-scaling.
Basically, your app will scale, by default, to handle your future business needs. And this reflects in the costs, as well: you'll get charged only for the computing resources that you'll use.
4.6. You App Supports Auto-Provisioning
Just imagine: your business-critical app will run non-eventful, using an on-demand allocation of services right from the app.
It will automatically tap into self-service and programmatic provisioning, so you don't need to manually provide them with the resources they need to run smoothly.
4.7. You'll Provide a Better Customer Experience
And it's quite predictable since the cloud-native principles revolve around a fast shipment of new features and continuous iteration.
The END!
Is my answer to your “What is a cloud-native application” question clear enough? And what about the above-listed reasons to opt for this type of app development architecture?
Are they relevant enough for your own scenario?
Image by Clker-Free-Vector-Images from Pixabay
RADU SIMILEANU / Jul 22'2019
Just imagine: you update content on one of your Drupal websites and it gets automatically synchronized across your whole network! That's Drupal on Blockchain in just a few words...
Say you manage a national library's infrastructure of Drupal websites. One for each one of its local branches.
Now, here's how moving all the user data stored in there from your centralized database onto a decentralized blockchain system would benefit you:
readers get to validate their own user data since there's no central entity having full (and exclusive) control over it
once they've updated their user data on one of the library's websites, it'll get synchronized across the entire network
the well-known vulnerability to errors of centralized multi-site structures gets eliminated; there's no longer a centralized database acting as a single point of failure
the decentralized architecture speeds up any operation that gets performed across the network
you'd avoid scenarios where the same reader enters his login credentials on one of the library's websites and gets asked to enter them, once again, when accessing the website of another library branch
And I would also add: increased transparency, lower transaction costs...
But I'd better dive into more details on how Blockchain and Drupal can work together and how you can benefit from the decentralized architecture that they'd put together:
1. Blockchain: What You Need to Know About Its Potential
But first, here's Blockchain in plain words:
A decentralized shared system where multiple participants store their data, interact directly with each other, manage and keep record of their transactions.
How is it different from the “old” way of managing transactions across a network?
there's no more a centralized database for storing data and transactions; participants (nodes) store it among themselves
… this grants them total control over their own data/created content
users involved in a blockchain network get to interact with one another freely, with no need of a third-party as an intermediary
it establishes a system of rule-based transactions
each transaction — editing, deleting content, etc. — gets documented
it enhances communication between nodes/participants
transactions get carried out at higher speed and, implicitly, with fewer costs
with no central entity as a unique storage source, there's no single source of failure anymore
enhanced transparency
In short: blockchain enables you to set up a secure and immutable architecture for your network.
2. Blockchain and a New Content Distribution Model
“Transparency” is the keyword here. Decentralizing a content distribution platform would benefit both content creators and content consumers:
digital publishers become the only ones allowed to update or delete their own content
consumers pay producers directly for the content they consume (written content, songs, videos, etc.)
This way: content creators get full control over their own content — there's no platform owner who could remove it to his/her liking — and get paid fairly and in real-time, for each piece of content that gets “consumed”.
3. Drupal on Blockchain: Why, How, and With What Costs?
Why would you want to decentralize your CMS — in this case, Drupal — and store your data on Blockchain?
To answer your question, let me highlight just a few of the inconveniences of managing your content on a centralized Drupal database:
each transaction is explicit and irreversible
it poses a higher vulnerability to errors
multiple-user functionality can turn out to be a serious dread
the centralized database acts as a single point of failure: if something crashes in there, the whole system is at risk
updating content in your database doesn't automatically update it across your entire network of Drupal websites...
And how would the 2 technologies work together? Considering the fundamental differences between them:
Drupal uses a centralized architecture to manage content
Blockchain uses a decentralized, middleman-free workflow based on a verification element
Before I try to answer your legitimate question, let me ask you this:
Do you seize any similarity between Drupal's “open data” phylosophy and Blockchain's “decentralized data” principle?
Now, here's how your hypothetical “Drupal on Blockchain” architecture would look like:
it'd be a much more secure, decentralized structure (you'd remove the single point of failure, remember?)
since a blockchain workflow would use an immutable validation of data, it'll act as a guarantee that no content can get modified by other than its creator/distributor
user data/content would be easily accessible across the entire infrastructure (take the example of an enterprise-level business, running a multi-site Drupal network)
… and it'd synchronize in real-time across all your Drupal instances, as well...
transactions performed within this architecture would be rule-based: every single content update or removal will get documented
“But at what costs?” you might ask. What compromises would you need to make to run Drupal on Blockchain?
What challenges should you get prepared for?
Here are 2 potential “dares” to ponder upon:
first of all, integrating your current Drupal data into a blockchain system won't be quite a “piece of cake”
secondly, getting the consensus of all the participants (say users whose data would be easily accessible network-wide) is also a serious issue to consider
4. Drupal Development Efforts in this Direction: The Blockchain Module
This duo — Drupal and Blockchain — has generated quite a lot of talk these years. And quite a handful of promising initiatives and even prototypes have been presented (integrations with Etherium and bitcoin...)
From all these initiatives of the Drupal community, I've decided to put the spotlight onto the Blockchain module (not yet covered by Drupal's privacy policy).
Take it as a “scaffolding” to support your future “Drupal on Blockchain” architectures. It provides the functionality you need to:
set up your Drupal installations as blockchain nodes; ”nodes” that are independent, meaning they can get configured independently
ensure that your newly set up nodes are compatible with each other
The END!
This is the “why, how and at what costs” of this topic. One which has been on the lips (and on the Drupalcon slides) of members of the Drupal community for quite a while now.
What do you think?
Would such a decentralized Drupal on Blockchain architecture suit your own project's needs and constraints? Would you trade your central point of storage for the convenience of automated content synchronization?
Photo by Clint Adair on Unsplash
RADU SIMILEANU / Jun 28'2019
This is no news anymore: preparing to upgrade to Drupal 9 is just a matter of... cleaning your website of all deprecated code.
No major disruption from Drupal 8. No more compatibility issues to expect (with dread)...
“Ok, but how do I know if my website's using any deprecated APIs or functions? How do I check for deprecations, identify them and then... update my code?”
2 legitimate questions that must be “haunting” you these days, whether you're a:
Drupal 8 website owner
developer currently working on a Drupal project
Since the great news of this smooth Drupal upgrade ships with the answer to your “What” question (“What do I do to get my website ready for Drupal 9?”), but leaves the “How” question open:
“How precisely do I check my website for deprecated code?”
Are there any analysis tools available? Tools that you could run to get a thorough and accurate deprecated code report?
Luckily, there are. And I'll be focusing on 2 of the most effective ones that you should consider integrating into your workflow: Drupal Check and the Upgrade Status module.
1. But What Is Deprecated Code? And What Website Elements Should You Audit?
A piece of code is considered deprecated if:
there's an upgraded alternative for it already available
it's no longer in use
With this real “dilemma” now solved, there comes another one:
“What parts of my website should I check for deprecated code?”
Make sure you scan your:
Drupal core
Drupal modules
theme
Note: pay special attention to the contributed modules enabled on your Drupal 8 website; run a deep-scan and, if you get any deprecation warnings, make sure to alert those modules' maintainers to clean them up.
2. Drupal Check: Scan Your Database for Any Deprecations
A handy PHP analysis tool to grab and to run whenever you need to look for deprecated code in your database.
A command-line tool that Dries Buytaert recommends running the... automated way, closely integrated into your own workflow. What it'll do is track down instances of deprecated code for you.
Then, all there's left for you to do is to... remove them. And, depending on the context, to replace them with their upgraded alternatives.
3. The Upgrade Status Module: Determine Your Site's Readiness to Upgrade to Drupal 9
If the idea of working with a command line doesn't sound too... “tempting” to you, how about adding a user-friendly graphical interface to the equation?
The Upgrade Status module, delivered to us by the Aquia team, led by Gábor Hojtsy, makes checking for deprecated code a lot more enjoyable and intuitive, thanks to its admin dashboard.
It's particularly handy if you're a Drupal site owner and not a senior Drupal developer highly familiar with CLIs.
Install it, enable it and use it to evaluate your website and to assess to what degree it is ready (meaning up to date) for the Drupal 9 upgrade.
But let's delve head first into details on:
what it takes to install it properly
what parts of your website it will deep scan
how you can narrow down its analysis to specific projects only
3.1. Use the Composer Package Manager to Install It
Since it ships with its whole collection of third-party PHP dependencies...
Another key requirement to set the stage for the Update Status module is to enable the Update Manager and the Git Deploy modules on your Drupal 8 website.
Once installed, you can access its user interface at /admin/reports/upgrade.
3.2. Check Up Your Codebase, Modules, and Themes
The great thing about this module is that you get to run your checks right in your admin UI and get a full report.
Another great aspect is that, when it comes to contributed modules, it will provide you any available updates... inline.
Once it's completed its scan it'll display either an “Errors found” or a “No known errors” message. To localize the identified deprecations on your website, just click “View errors”.
3.3. Run It on Specific Individual Projects, Too
Maybe you don't always need a full check. Maybe you'd like to scan only a specific project that you might be working on, to ensure that it's ready to upgrade to Drupal 9 when due time.
You can do that. The module allows you to cut down the time you'd spend on an unnecessary full-scan by focusing on one target project only.
Furthermore, to streamline things even more, it enables you to export each deprecated code report individually...
4. So, You'Ve Identified Your Deprecated Code: What Next?
In most cases, keeping your codebase up to date once you've detected the deprecated parts is just a matter of replacing those deprecations.
For the other few cases left, you'll need to carry out a more complex refactoring process.
Now that you know which are the tools to use for:
running your audits
spotting any deprecations in your codebase
… your website's smooth upgrade to Drupal 9 depends on you exclusively.
On sticking to your own routine of checking up your Drupal core, modules and theme and keeping them up to date.
Image by fajar budiman from Pixabay
RADU SIMILEANU / Jun 21'2019
What makes the Cache API in Drupal 8 any better than Drupal 7's cache system? What's so revolutionary about it? Which of the old limitations does it remove? What are those new concepts and terminology that you should learn about?
And, most of all: how complex is it to set up a cache in Drupal 8 for a specific use case?
You might have already bumped into terms like “max-age”, "context cache" or "cache tags".
But how precisely do these new concepts, part of Drupal 8's cache system, refine and streamline the way you cache data on your website?
Let's try to demystify the terminology of Drupal 8's Cache API and to translate its new “fancy” terminology into... crystal-clear benefits for you:
1. What Is Caching More Precisely? Why Do We Cache Data?
To your “What” question I'd answer:
Caching is a... strategy (or layer) for storing data from your website. Or: it's a software or hardware component where you store your data.
Why would you want to store your data?
Because this will streamline the way your website serves all future requests for that cached data.
And it goes without saying that reading data straight from the cache takes less time than... retrieving it from a slower data container or fully recreating the result.
In short: caching data translates into faster page load time.
2. Cache API in Drupal 8: The Automatic Cache System
A brief, yet accurate definition of cache in Drupal 8 would be:
Storing data that takes too long to load.
And if I am to detail it a bit I'd have to add that:
Caching can be either permanent or time-limited and that you're free to cache any type of data on your website.
Now, talking about Drupal 8's cache API, what everyone points out is that: it is much improved. That it's so different from the cache systems of the previous Drupal versions that... you even risk turning your website uncachable if you're not familiar with its new concepts.
“But how different/sophisticated can it be?” you might ask yourself.
Before we delve deep into details let me add just one thing:
We're talking about an... automated cache system. Basically, your Drupal 8 website retrieves cache data for both anonymous and logged in users with no configuration whatsoever. All by default.
And now, let's shed some light on all these new fancy concepts that the Cache API in Drupal 8 is based on:
2.1.The Cache Tags
We all do agree that “invalidating cache” is one of the most challenging tasks of any cache system.
Luckily, not anymore. At least not in Drupal 8, where you now have the concept of “cache tags” that you can use for tagging:
specific pages
specific page elements
various types of content
… and thus invalidate them all. Improved efficiency and high accuracy through... basic tagging.
Basically, using these cache tags you can easily identify outdated data stored in multiple cache bins and... invalidate it.
This way, you no longer run the risk of invalidating “still green” cache items, in bulk, not knowing which data to invalidate.
2.2. The Context Cache
Here's an all too common scenario:
You're faced with multiple variants of the same data; only one of them should be cached, based on a specific criterion like language, user, country, content access permission...
Well, how do you automate targetting the right variant to be cached? And how do you automate caching the other left variants, as well, depending on the... context.
You use “cache contexts”, that's how...
They're one of those new remarkable features that the Cache API in Drupal 8 ships with, that allow you to specify the criteria to be used to vary for the cached content on a page. By user, by language, by country, by path...
2.3. The Max-Age (The Cache Duration)
Maybe you don't want certain data to be forever cached. Maybe you need it stored for a certain period of time only.
In this respect, the “max-age” property in Drupal 8's cache system allows you to define that time limit. To invalidate data that will have run... out of time.
2.4. The Bubbleable Cache Metadata
What does this even mean “cache metadata... bubbling”?
Let's take this example:
You have a parent item with its own “family” of... children items. In this context, “bubbled tags” makes it possible for the parent item in this render array to receive cacheability metadata from its children.
Bubble cache metadata streamlines the whole process of invalidating outdated cached data. As simple as that...
The END!
Is it any clearer for you now what makes the Cache API in Drupal 8 so powerful? How its new features come to remove most of the limitations that you've already faced in Drupal 7?
And how you can use them to refine and automate caching on your own Drupal 8 website?
Image by Pexels from Pixabay
RADU SIMILEANU / May 24'2019
How is Kubernetes any better than... standard virtual servers? What are those unquestionable benefits of using Kubernetes?
What are its features, first of all?
And what are... containers? What specific needs does a container orchestration tool come to address? In this respect, why would you use Kubernetes over... Docker, for instance?
Let's dig up its unique features and most compelling benefits:
1. But First: What Are Containers More Precisely?
Before we (even) attempt at defining Kubernetes we need to... define containers, right?
They're (mini) virtual machines that deploy ready-to-run applications on other virtual machines (or host OS)...
The conveniences they provide?
they're smaller, lighter (considering that apps usually need just the bare essential in terms of operating systems to run on)
they streamline app deployment
they're the guarantee that those virtual machines are used at their full capacity
they can be run just like any VM template: with no configuration (or hardly any)
Note: you can find tons of preconfigured Docker images in Dockerhub. The bundles of convenience come from the fact that you're free to scan through and download the needed nginx as well as complex items without worrying about configuring them.
Other developers have invested their time and knowledge to set up all the due software configurations for you...
2. What Is Kubernetes in Simple Words?
Going back to containers, we're faced with a specific need: that of keeping a close track of them.
How do you monitor your virtual machines? How do you identify, let's say, those that keep running pointlessly? Without doing... anything in fact?
Also, by keeping track of your current containers, you'd be able to easily spin up a few more when you need more CPU, storage or memory...
This is where a cluster container orchestration tool comes in handy. A tool like... Kubernetes.
What it does, precisely, is to streamline the whole process of managing your containers, enabling you to leverage their full potential.
In short, by using Kubernetes you can easily deploy your containers to clusters (“ecosystems” of virtual machines). You get just one interface that you can use for deploying your containers to:
virtual machines
physical machines
multiple types of clouds...
And where do you add that it's designed to manage a wide range of container types. Not just Docker containers.
Note: Google, its creator, has been using it for 10 years. Now, just try to imagine all their heavy systems running on this particular container management tool! They must have “stuck” to Kubernetes for a good reason...
Luckily for us, Kubernetes joined the “club” of the open source technologies 2 years ago. Furthermore, it's now a managed service on Azure and Google Cloud, as well.
3. Why Should You Care? 7 Key Benefits of Using Kubernetes
Why would you use Kubernetes? The long-term payoffs must to be more than “tempting”, considering that the learning curve is quite steep.
And they are...
Here, I've selected the 7 best possible answers to your “Why should I use Kubernetes?” question:
3.1. It works smoothly with Node apps
Which means that you get to run any type of application with it.
3.2. It reduces and simplifies...
2 of the main benefits of using Kubernetes is that:
it cuts down cloud computing costs
it simplifies operations and trims down your container architecture...
3.3. It helps you get the most of your hardware resources
And here I'm referring to network bandwidth, memory, storage I/O...
How does it help you maximize the way you use them?
it helps you automate the whole process of updating your cluster (and respectively rolling back those updates, when necessary)
it bundles together, on the very same hardware, all those apps that use minimal resources
it places those applications "in need for" more resources on systems that can better cope with their “needs”
In short: Kubernetes will optimize the use of hardware resources.
3.4. It's easy to use
Compared to other container management engines and despite its high learning curve.
3.5. It speeds up the development process
This is another one of the undeniable benefits of using Kubernetes. How precisely does it boost the development cycle?
it runs all the needed updates
it performs automated deployments, operations across multiple clusters of hosts, scaling...
it manages all your apps and services included in your infrastructure with minimum downtime
3.6. It ships with a self-healing mechanism
From re-scheduling to auto-restarting, to replicating containers, Kubernetes' self-healing system is one of its strongest points.
Basically, it lifts the time-consuming burden of keeping your app up to date and perfectly adapted to users' latest expectations.
It will restart services when trouble strikes: it will address all the “health issues” that might occur and get your app automatically “cured”.
3.7. You Can Run Your App in Both Hybrid and Multi-Cloud Environments
Just imagine: Kubernetes enables you to leverage features specific to multiple individual clouds.
Basically, you're free to run your Kubernetes application in any cloud or “combo” of public or private clouds.
Using its own set of primitives — federation — it's designed to synchronize multiple clusters, placed across different clouds and regions...
4. When Is Kuberentes the Best Choice?
First of all, Kubernetes makes a great choice when it's a highly available distributed system that you have in mind.
Secondly, choose it when the convenience of using the same CLI for orchestrating all your different systems is of particular importance to you.
Just think: is it crucial for you to have just one CLI for pushing your containers to various different clouds (the Amazon cloud here included), to your physical and in-house machines...?
The END!
Are these 7 answers on the benefits of using Kubernetes convincing enough for you?
Image by RSunset from Pixabay
RADU SIMILEANU / Apr 19'2019
Why would you still want to opt for a Drupal multisite setup? What strong reasons are there for using this Drupal 8 feature?
I mean when there are so many other tempting options, as well:
you could use Git, for instance, and still have full control of all your different websites, via a single codebase
you could go with a Composer workflow for managing your different websites
On one hand, everyone's talking about the savings you'd make — of both time and money — for keeping your “cluster” of websites properly updated. And yet, this convenience comes bundled with certain security risks that are far from negligible.
Just think single point of failure...
Now, to lend you a hand with solving your dilemma, let's go over the key Drupal multisite pros and cons. So that, depending on your:
developers' skill level
current infrastructure
project budget
hierarchy of priorities
host capabilities
multi-site infrastructure's specific needs
… you can decide for yourself whether a Drupal multisite setup does suit your situation or you'd better off with one of its valid alternatives.
And whether you agree that it should eventually get removed from Drupal 9.x or not.
1. Drawbacks for Using the Multisite Feature/Arguments for Removing It
Now, let us expose this built-in Drupal feature's main limitations. Those that might just make you think twice before using it:
there's no way to update the core of just one Drupal website from your setup; you're constrained to update them all at once, every single time
it becomes quite challenging to assign a team with working on one (or some) of your websites only
it's not as richly documented as other built-in features (especially if we consider its “age”)
it exposes your Drupal multisite setup to security vulnerabilities; it's enough for one website from the “cluster” to get corrupted (accidentally or intentionally) for all the other ones to get infected
reviewing code becomes a major challenge: you can't “get away with” writing code for one website only; instead, you'll need to rewrite code on all your websites included in the setup, to test it against all breakpoints and so on...
putting together test and state environments gets a bit more cumbersome
in order to efficiently manage such an infrastructure of websites strong technical skills are required; are there any command-line experts in your team?
having a single codebase for all your Drupal websites works fine if and only if they all use the same settings, same modules; if not, things get a bit... chaotic when, for instance, there's a security issue with one module, used on all your websites, that affects your entire ecosystem
also, since your shared database is made of a wide range of tables, when you need to migrate one site only, you'll have “the time of your life” trying to identify those tables that belong to some websites and those that they all share
2. Top 3 Reasons to Go With a Drupal Multisite Setup
Now that we've taken stock of the main drawbacks for leveraging this Drupal feature, let's try to identify the main reasons for still using it:
A heavy-weighing reason is given by the time and money you'd save on updating your “cluster” of sites. With the right experience in using the command-line you can run the due updates in just one codebase and have them run across all your websites simultaneously
It's an approach that becomes particularly convenient if you need self-hosting for your setup (e.g. take the case of a university hosting all its different websites or a Drupal distribution provider...)
You'd be using less memory for OpCache and this benefit becomes particularly tempting if you're dealing with RAM constraints on your servers
3. In Conclusion...
There still are solid reasons to opt for a Drupal multisite setup. Reasons that could easily turn into strong arguments for not having it removed in Drupal 9.x...
But there are also equally strong reasons for getting discouraged by the idea of leveraging this age-old feature. And where do you add that from Docker to Composer and GIT, you're not running out of options for managing your “cluster” of websites.
In the end, the decision depends on your situation, that's made of specific factors like budget, hosting capabilities, whether your websites are using the same modules, etc.
The answer to your “Are there any valid reasons for using the Drupal multisite feature?” cannot be but:
“Yes there are, but counterbalanced by certain disadvantages to consider.”
Image by Arek Socha from Pixabay
RADU SIMILEANU / Apr 03'2019
Planning to build a social network with Drupal? A business community maybe? A team or department collaborating on an intranet or portal? Or a network grouping multiple registered users that should be able to create and edit their own content and share their knowledge? What are those key Drupal 8 modules that would help you get started?
That would help you lay the groundwork...
And there are lots of social networking apps in Drupal core and powerful third-party modules that you could leverage, but first, you need to set up your essential kit.
To give you a hand with that, we've selected:
5 modules in Drupal 8, plus a Drupal distribution, that you'll need to start a perfectly functional social networking website, with all the must-have content management features and knowledge sharing tools.
Before You Get Started: A Few Things to Take Care Of
First of all, let me guess the features on your must-have list:
articles
groups
photos
user profiles
groups
forums
It should feature pages with dynamic content leveraging a fine-grained access system and social media hubs, right?
Well, now that we've agreed on this, here are the preliminary steps to take before you get actually started, installing your key modules and so on:
configure your “Taxonomy” categories after you've installed the Forum module
set up a custom content type for Blog posts
set up your thumbnail settings for the Article nodes
create your key user roles (admin, content author, paid subscriptions)
use the PathAuto module to define your URL path structure
define your Article nodes' thumbnail settings and remember to upload an anchor image, as well
1. Panels
Panels and Views make a “power team” to rely on for setting up pages with dynamic content for your social networking site.
What makes it a must-have module to add to your essential kit when you build a social network with Drupal?
It enables you to create custom layouts for multiple uses.
You get to use it to set up your website's homepage, one featuring multiple Views blocks with dynamic content retrieved from forums, articles, blogs...
Feel free to add a top slideshow image, to go for multiple-tiled stacked layout, including views from forum, blog and article posts...
In short: the Panels module empowers you to get as creative as possible when setting up fine-tuned layouts for your landing pages displaying dynamic content.
2. Views
Not only that it enables you to present content to your social network's registered users in pretty much any form you might think of — tables, lists, blocks, forum posts, galleries, reports, graphs — but it also:
enables you to display related content (e.g. display a list of the community members along with their pieces of content)
enables you to use contextual filters
It'll turn out to be one of the handiest Drupal 8 modules in your toolbox when you need to create and display dynamic content from:
forums
blocks
blogs
Yet, maybe one of the most common use cases for the Views module on a social networking website is that of:
Setting up a (Views) page listing all the article posts.
3. Blog
Another module you'll most certainly want to add to your social networking website as it:
enables both single and multi-user blogs
empowers authorized site members to maintain it
Speaking of which, blog entries can be either public or private for a specific user, depending on the role he/she's assigned with.
And it's precisely that system of user roles and corresponding permissions set up on your website that will determine whether a member can:
access the “Create Content” link or not
access a “My Blog” section or... not
You can further leverage this Blog module to add a “Recent blog posts” block to your webpages, in addition to the “Blogs” navigation link on your main navigation menu.
4. Profile, a Must-Have Module to Build a Social Network with Drupal
You just can't imagine that you could build a social network with Drupal without a module enabling you to create registration page fields, now can you?
Well, here it is: the Profile module.
And here are its “superpowers”:
it enables configurable user profiles
it enables expanded fields on the user registration page
it provides social network members with two different links, one for their account settings, one for their user profiles
it provides private profile fields (that only the admin and that specific user can access)
it enables you to set up different profile types for different user roles with... different permissions granted
5. Group
The sky is the limit in terms of what the Group module enables you to do when you build a social network with Drupal:
it powers pretty much any scenario you can think of, from subgroups to specific per-group behavior, to access permissions...
it enables you to put together content collections on your website and grant access to it based on your user roles and permissions policy
it enables you to easily add relevant metadata to define the group & content relationships on your site
it enables you to control all your settings via a user-friendly admin UI; no need to write custom code to determine what each group is allowed and not allowed to do on your social network
Open Social
I just couldn't help it...
Even though this was supposed to be a roundup of those essential modules you'll need to build a social network with Drupal, I had to add this Drupal distribution, as well.
Open Social is that out-of-the-box solution that you can leverage to get your online user community up and running in no time.
An open source software with all the needed features and functionality already pre-built, so that you can enable members on your network to:
work together
share knowledge
organize events
Convenience at its best when you want to start a social networking website without worrying much about:
installing a whole collection of modules
doing custom work in the “backstage”.
The END!
This is the minimal kit you'll need to build your online community website with Drupal.
Would you have added other essential modules to the list?
RADU SIMILEANU / Mar 16'2019
Why not stick to a traditional web hosting server? Why use a CDN, as well?
After all, you can run your website, upload your videos and images and deliver content to your website visitors without relying on a CDN, right? Why bother, then?
Do the benefits outweigh the costs?
And is faster content delivery the only major advantage for implementing it?
Now, let's look for some straight answers:
1. What Is CDN?
It's a network of nodes...
Nodes that are, in turn, mini-networks of systems and servers.
What all these clusters of servers do is store content as cache (graphics, media files, text, documents, live video streaming data, scripts etc.) and serve it to their nearest users.
The main benefit of using a CDN is the reduced distance that the data request would need to travel from the browser to the central data location. And also the reduced distance of the retrieved content from the server back to the end user's web browser.
In this case, there would always be a server closer to the website visitor to process his request in a shorter time.
Just imagine this benefit in the context of a peak load, like a flash sale on your website, with users from all over the globe flooding in.
2. Why Use a CDN: 8 Powerful Benefits
2.1. It Reduces Your Web Page Load Times
The significant push that a CDN gives to content delivery is the top reason why website owners opt for a CDN.
The process behind it, the main “culprit” for the reduced page load times, can get summed up to this:
A CDN would always retrieve data from its nearest node.
The shorter the distance for the content request to go through, the quicker the page receiving that data will load.
As simple as that...
2.2. It Secures Your Website Against DDoS Attacks
But first: “What are DDoS attacks?”
They're those types of attacks when a hacker holds the resources on your server by “overwhelming” it with a heavy load. One causing your website to crash down...
Now, how would a CDN help you prevent these malicious attempts? What does a CDN do, more precisely?
It enables you to implement WAFs (web application firewalls) and “origin shields”, that will mitigate any attempt of a DDoS attack.
And, since we've tackled the “boosted security” aspect, here are some other ways that a CDN can tighten the shield around your website:
the CDN edge servers: they withhold the heaviest load on your website, keeping it up and running even at traffic peaks; any attack on your server will first have to go through these edge servers, which, due to the decentralization of the data, won't bail on you
you get to opt for a proxy and thus hide the origin of your IP address
you can implement an SSL; even if the attackers manage to take over your server's resources, their access will then automatically... self-expire.
2.3. Your CDN-Based Website Gets Robust Enough to Withstand Peak Traffic
Why use a CDN?
Because it doesn't fail on you/your website when heavy loads of traffic strike.
Thanks to its evenly distributed network of nodes, it's equipped to withstand any traffic “tsunami”. If one node fails, there's always a neighboring server ready to back it up and take on the load.
2.4. You'd Cut Down On Your Bandwidth Costs
How? Well, it's quite obvious:
with multiple edge servers installed in a CDN, you reduce the strain put on your hosting server (your origin server); the load will then get distributed among the CDN nodes
therefore, you'd offload CPU and use less server resources
which will automatically translate into a lighter bill from your web hosting provider
Just imagine the bandwidth you'd save at traffic spikes...
And there's more!
Another benefit of using a CDN is that it provides hotlink protection.
This way, you can prevent others from embedding your assets on their own websites (which would otherwise turn into a “surprise” cost on your bill)
2.5. It's More Cost-Effective in the Long Run
When you hear of giants like Netflix implementing a CDN solution you inevitably tell yourself:
“Yes, but they can afford it."
Time to bust this myth that a CDN integration is highly expensive once and for all.
Just think about it:
A CDN would handle +60% of the total load on your website. So, your origin server would be using less bandwith for bearing its share of the load. That can only lead to a “friendlier” bill from your hosting provider.
In short: a CDN is less costly in the long run.
2.6. Higher Ranks in the SERPs & Enhanced User Experience
And high loading speed is user experience...
Your website visitors will benefit from the speed that a CDN “injects” into your website, whereas Google will reward it with a push in the SERPs.
Use a CDN for images, since it's geared at increasing the crawl rate of media content (e.g. images).
In a traditional web hosting scenario, you'd have to restrain yourself from uploading too many images, since they're the main “culprit” for low page loading speed.
That's not the case when you have a CDN solution hosting them...
2.7. It Helps Your Website Overcome the Scalability Hurdle
Why use a CDN?
Because it's built with scalability in mind.
Scalability which goes hand in hand with... availability.
If, at some point, you need to expand to new geographic locations, your CDN will have got your covered:
The cached content on your website will be available across a whole network of POPs, located in different regions. Therefore, any high load of traffic will be dynamically routed from one server to another, if one happens to... succumb.
No matter the scalability challenge that your website might be faced with, you can be sure it will manage to deliver its content at high speed.
2.8. Faster Streaming Video
And this is no negligible benefit of using a CDN since video content's been ruling supreme for a while now.
By cutting down the time-frame, a CDN geared at delivering dynamic content will automatically reduce the video latency.
The time elapsed from the instant that a request is submitted to the moment it gets a response from the server is drastically shorter.
The END!
Have you got your answer now to the “why use a CDN?” question?
Photo by Ken Treloar on Unsplash.
RADU SIMILEANU / Mar 08'2019